Date:	Thu, 22 Dec 2011 10:53:57 -0800
From:	Frank Rowand <frank.rowand@...sony.com>
To:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
CC:	"Rowand, Frank" <Frank_Rowand@...yusa.com>,
	Anton Vorontsov <anton.vorontsov@...aro.org>,
	David Rientjes <rientjes@...gle.com>,
	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-mm@...ck.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Johannes Weiner <hannes@...xchg.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	"tbird20d@...il.com" <tbird20d@...il.com>
Subject: Re: Android low memory killer vs. memory pressure notifications

On 12/21/11 17:16, KOSAKI Motohiro wrote:
>>> 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.
>>
>> A comment from http://lkml.indiana.edu/hypermail/linux/kernel/1102.1/00412.html:
>>
>> "I care about 5K. (But honestly, I don't actively hunt stuff less than
>> 10K in size, because there's too many of them to chase, currently)."
> 
> Hm, interesting. Because of, current memory cgroup notification was
> made by a request from Sony and CELinux. AFAIK, at least, Sony
> are already using cgroups.

Sony makes a very large range of products.  The memory available on the
different products can range from a few megabytes to hundreds of megabytes
(and I wouldn't be surprised if the top of the range is gigabytes).

Our low memory products lead us to be concerned about the growth in
memory usage by newer kernel versions.  Of course we also like additional
features and kernel improvements, so we understand the balancing act of
features requiring more memory, while at the same time discouraging
memory growth for resource constrained systems.  Config options are
one of the tools used to manage that balancing act.

>>> 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 for embedded and for real-time, some of us do not want cgroups to be
>> a mandatory thing.  We want it to remain configurable.  My personal
>> interest is in keeping the latency of certain critical paths (especially
>> in the scheduler) short and consistent.
> 
> As far as I observed, modern embedded system have both RT and no RT process.
> Java VM or user downloadable programs may need memory notification
> because users may download bad programs. in the other hand, rt
> processes are not downloadable and much tested by hardware vendor. So,
> I think you only need
> split process between under cgroups and not under cgroups.
> 
> cgroups have zero or much likely zero overhead if the processes don't use it.
> Of course, feedback are welcome. I'm interesting your embedded usecase.

No, cgroups have _near_ zero overhead when the cgroup configuration option is
turned off. :-)  (Sorry, being pedantic, but still serious.)

Again, we have many different products.  Some may find cgroups to be useful.
But at least one of our product groups totally removed the cgroups source code
from their scheduler as part of their focus on reducing latency.

We have to think about a wide range of (sometimes conflicting)
requirements.  Config options help us choose which features to enable
for each product, resolving some of the conflicting requirements.

-Frank

--
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