Re: [PATCH 0/2] Fix memcg/memory.high in case kmem accounting is enabled

[Vladimir Davydov]

Hi Tejun, Michal

On Fri, Sep 04, 2015 at 11:44:48AM -0400, Tejun Heo wrote:
...
> > I admit I may be mistaken, but if I'm right, we may end up with really
> > complex memcg reclaim logic trying to closely mimic behavior of buddy
> > alloc with all its historic peculiarities. That's why I don't want to
> > rush ahead "fixing" memcg reclaim before an agreement among all
> > interested people is reached...
> 
> I think that's a bit out of proportion.  I'm not suggesting bringing
> in all complexities of global reclaim.  There's no reason to and what
> memcg deals with is inherently way simpler than actual memory
> allocation.  The original patch was about fixing systematic failure
> around GFP_NOWAIT close to the high limit.  We might want to do
> background reclaim close to max but as long as high limit functions
> correctly, that's much less of a problem at least on the v2 interface.

Looking through this thread once again and weighting my arguments vs
yours, I start to understand that I'm totally wrong and these patches
are not proper fixes for the problem.

Having these patches in the kernel only helps when we are hitting the
hard limit, which shouldn't occur often if memory.high works properly.
Even if memory.high is not used, the only negative effect we would get
w/o them is allocating a slab from a wrong node or getting a low order
page where we could get a high order one. Both should be rare and both
aren't critical. I think I got carried away with all those obscure
"reclaimer peculiarities" at some point.

Now I think task_work reclaim initially proposed by Tejun would be a
much better fix.

I'm terribly sorry for being so annoying and stubborn and want to thank
you for all your feedback!

Thanks,
Vladimir
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/