linux-kernel - Re: [PATCH] mm: memcontrol: reclaim when shrinking memory.high below usage

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, 11 Mar 2016 17:01:46 +0300
From:	Vladimir Davydov <vdavydov@...tuozzo.com>
To:	Michal Hocko <mhocko@...nel.org>
CC:	Johannes Weiner <hannes@...xchg.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	<linux-mm@...ck.org>, <cgroups@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <kernel-team@...com>
Subject: Re: [PATCH] mm: memcontrol: reclaim when shrinking memory.high below
 usage

On Fri, Mar 11, 2016 at 02:39:36PM +0100, Michal Hocko wrote:
> On Fri 11-03-16 14:49:34, Vladimir Davydov wrote:
> > On Fri, Mar 11, 2016 at 10:53:09AM +0100, Michal Hocko wrote:
> > > > OTOH memory.low and memory.high are perfect to be changed dynamically,
> > > > basing on containers' memory demand/pressure. A load manager might want
> > > > to reconfigure these knobs say every 5 seconds. Spawning a thread per
> > > > each container that often would look unnecessarily overcomplicated IMO.
> > > 
> > > The question however is whether we want to hide a potentially costly
> > > operation and have it unaccounted and hidden in the kworker context.
> > 
> > There's already mem_cgroup->high_work doing reclaim in an unaccounted
> > context quite often if tcp accounting is enabled.
> 
> I suspect this is done because the charging context cannot do much
> better.
> 
> > And there's kswapd.
> > memory.high knob is for the root only so it can't be abused by an
> > unprivileged user. Regarding a privileged user, e.g. load manager, it
> > can screw things up anyway, e.g. by configuring sum of memory.low to be
> > greater than total RAM on the host and hence driving kswapd mad.
> 
> I am not worried about abuse. It is just weird to move something which
> can be perfectly sync to an async mode.
>  
> > > I mean fork() + write() doesn't sound terribly complicated to me to have
> > > a rather subtle behavior in the kernel.
> > 
> > It'd be just a dubious API IMHO. With memory.max everything's clear: it
> > tries to reclaim memory hard, may stall for several seconds, may invoke
> > OOM, but if it finishes successfully we have memory.current less than
> > memory.max. With this patch memory.high knob behaves rather strangely:
> > it might stall, but there's no guarantee you'll have memory.current less
> > than memory.high; moreover, according to the documentation it's OK to
> > have memory.current greater than memory.high, so what's the point in
> > calling synchronous reclaim blocking the caller?
> 
> Even if the reclaim is best effort it doesn't mean we should hide it
> into an async context. There is simply no reason to do so. We do the
> some for other knobs which are performing a potentially expensive
> operation and do not guarantee the result.

IMO it depends on what a knob is used for. If it's for testing or
debugging or recovering the system (e.g. manual oom, compact,
drop_caches), this must be synchronous, but memory.high is going to be
tweaked at runtime during normal system operation every several seconds
or so, at least in my understanding. I understand your concern, and may
be you're right in the end, but think about userspace that will probably
have to spawn thousands threads every 5 seconds or so just to write to a
file. It's painful IMO.

Are there any hidden non-obvious implications of handing over reclaim to
a kernel worker on adjusting memory.high? May be, I'm just missing
something obvious, and it can be really dangerous or sub-optimal.

Thanks,
Vladimir