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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 4 Sep 2015 21:21:11 +0300
From:	Vladimir Davydov <vdavydov@...allels.com>
To:	Tejun Heo <tj@...nel.org>, Michal Hocko <mhocko@...nel.org>
CC:	Johannes Weiner <hannes@...xchg.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Christoph Lameter <cl@...ux.com>,
	Pekka Enberg <penberg@...nel.org>,
	David Rientjes <rientjes@...gle.com>,
	Joonsoo Kim <iamjoonsoo.kim@....com>, <linux-mm@...ck.org>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/2] Fix memcg/memory.high in case kmem accounting is
 enabled

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/