Date:	Wed, 21 Dec 2011 04:28:53 +0400
From:	Anton Vorontsov <anton.vorontsov@...aro.org>
To:	David Rientjes <rientjes@...gle.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
Cc:	Michal Hocko <mhocko@...e.cz>,
	Arve Hjønnevåg <arve@...roid.com>,
	Rik van Riel <riel@...hat.com>, Pavel Machek <pavel@....cz>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	John Stultz <john.stultz@...aro.org>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, Johannes Weiner <hannes@...xchg.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: Android low memory killer vs. memory pressure notifications

On Tue, Dec 20, 2011 at 01:36:00PM -0800, David Rientjes wrote:
> On Tue, 20 Dec 2011, Anton Vorontsov wrote:
> 
> > Hm, assuming that metadata is no longer an issue, why do you think avoiding
> > cgroups would be a good idea?
> > 
> 
> It's helpful for certain end users, particularly those in the embedded 
> world, to be able to disable as many config options as possible to reduce 
> the size of kernel image as much as possible, so they'll want a minimal 
> amount of kernel functionality that allows such notifications.  Keep in 
> mind that CONFIG_CGROUP_MEM_RES_CTLR is not enabled by default because of 
> this (enabling it, CONFIG_RESOURCE_COUNTERS, and CONFIG_CGROUPS increases 
> the size of the kernel text by ~1%),

So for 2MB kernel that's about 20KB of an additional text... This seems
affordable, especially as a trade-off for the things that cgroups may
provide.

The fact is, for desktop and server Linux, cgroups slowly becomes a
mandatory thing. And the reason for this is that cgroups mechanism
provides some very useful features (in an extensible way, like plugins),
i.e. a way to manage and track processes and its resources -- which is the
main purpose of cgroups.

And that's exactly what we want for low memory killer -- manage processes
and track its resources.

No doubt that Android is very different from desktop and server Linux
usage, but that does not mean that it has to use different kernel
interfaces.


As Alan Cox pointed out, we should probably focus on improving (if needed)
existing solutions, instead of duplicating functionality for the sake of
doing the same thing, but in a more "lightweight" and ad-hocish way.

By going "alternative" (to cgroups) way, we're risking to end up with the
same thing but under some different name.

> and it's becoming increasingly 
> important for certain workloads to be notified of low memory conditions 
> without any restriction on its usage other than the amount of RAM that the 
> system has

I'm not sure what you mean here. Mem_cg may provide a way to the
userland to be notified on low memory conditions, i.e. amount of RAM
that the system has -- the same thing as /dev/mem_notify would do...

(Though, as of current mem_cg, I believe that root memory.usage_in_bytes
does not account memory used by the kernel itself, so today it seems not
possible to use 'memory thresholds' feature to track total amount of RAM
available in the system.)

> so that they can trigger internal memory freeing, explicit 
> memory compaction from the command line, drop caches, reducing scheduling 
> priority, etc.

Mem_cg provides a mere resources tracking and notification mechanism,
I'm not sure how it could restrict what exactly apps would do with it.
They as well may trigger internal memory freeing, drop caches etc., no?

Thanks!

-- 
Anton Vorontsov
Email: cbouatmailru@...il.com
--
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/

Powered by blists - more mailing lists