linux-kernel - Re: [RFC v3 0/3] vmpressure_fd: Linux VM pressure notifications

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 for Android: free password hash cracker in your pocket

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

Message-ID: <alpine.DEB.2.00.1211201013460.4200@chino.kir.corp.google.com>
Date:	Tue, 20 Nov 2012 10:23:11 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	Glauber Costa <glommer@...allels.com>
cc:	Anton Vorontsov <anton.vorontsov@...aro.org>,
	"Kirill A. Shutemov" <kirill@...temov.name>,
	Pekka Enberg <penberg@...nel.org>,
	Mel Gorman <mgorman@...e.de>,
	Leonid Moiseichuk <leonid.moiseichuk@...ia.com>,
	KOSAKI Motohiro <kosaki.motohiro@...il.com>,
	Minchan Kim <minchan@...nel.org>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
	John Stultz <john.stultz@...aro.org>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, linaro-kernel@...ts.linaro.org,
	patches@...aro.org, kernel-team@...roid.com,
	linux-man@...r.kernel.org,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Michal Hocko <mhocko@...e.cz>,
	Johannes Weiner <hannes@...xchg.org>, Tejun Heo <tj@...nel.org>
Subject: Re: [RFC v3 0/3] vmpressure_fd: Linux VM pressure notifications

On Mon, 19 Nov 2012, Glauber Costa wrote:

> >> Because cpusets only deal with memory placement, not memory usage.
> > 
> > The set of nodes that a thread is allowed to allocate from may face memory 
> > pressure up to and including oom while the rest of the system may have a 
> > ton of free memory.  Your solution is to compile and mount memcg if you 
> > want notifications of memory pressure on those nodes.  Others in this 
> > thread have already said they don't want to rely on memcg for any of this 
> > and, as Anton showed, this can be tied directly into the VM without any 
> > help from memcg as it sits today.  So why implement a simple and clean 
> > mempressure cgroup that can be used alone or co-existing with either memcg 
> > or cpusets?
> > 
> 
> Forgot this one:
> 
> Because there is a huge ongoing work going on by Tejun aiming at
> reducing the effects of orthogonal hierarchy. There are many controllers
> today that are "close enough" to each other (cpu, cpuacct; net_prio,
> net_cls), and in practice, it brought more problems than it solved.
> 

I'm very happy that Tejun is working on that, but I don't see how it's 
relevant here: I'm referring to users who are not using memcg 
specifically.  This is what others brought up earlier in the thread: they 
do not want to be required to use memcg for this functionality.

There are users of cpusets today that do not enable nor comount memcg.  I 
argue that a mempressure cgroup allows them this functionality without the 
memory footprint of memcg (not only in text, but requiring page_cgroup).  
Additionally, there are probably users who do not want either cpusets or 
memcg and want notifications from mempressure at a global level.  Users 
who care so much about the memory pressure of their systems probably have 
strict footprint requirements, it would be a complete shame to require a 
semi-tractor trailer when all I want is a compact car.

> So yes, *maybe* mempressure is the answer, but it need to be justified
> with care. Long term, I think a saner notification API for memcg will
> lead us to a better and brighter future.
> 

You can easily comount mempressure with your memcg, this is not anything 
new.

> There is also yet another aspect: This scheme works well for global
> notifications. If we would always want this to be global, this would
> work neatly. But as already mentioned in this thread, at some point
> we'll want this to work for a group of processes as well. At that point,
> you'll have to count how much memory is being used, so you can determine
> whether or not pressure is going on. You will, then, have to redo all
> the work memcg already does.
> 

Anton can correct me if I'm wrong, but I certainly don't think this is 
where mempressure is headed: I don't think any accounting needs to be done 
and, if it is, it's a design issue that should be addressed now rather 
than later.  I believe notifications should occur on current's mempressure 
cgroup depending on its level of reclaim: nobody cares if your memcg has a 
limit of 64GB when you only have 32GB of RAM, we'll want the notification.
--
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/