RE: [PATCH 3.2.0-rc1 0/3] Used Memory Meter pseudo-device and related changes in MM

[<leonid.moiseichuk@nokia.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2320 bytes --]

Hi,

We (small and embedded) needs some mechanism to notify userspace that memory consumption is going to be high to allow react properly and keep device fast and stable:  close big graphics, shuts something not used, stop processing data etc.  If we not able to do it in the right moment OOM killer starts to work and applications just disappears which is not nice for user in all cases. So the proposed code is not replacement of OOM killer at all but, yes, could be recognized as part of "cooperative-oom". 

Since n900 we tried to use memcg and notifications. Unfortunately memcg is not nice suitable to handling processes due to how memory is accounted: taking into account caches produce false-positive notifications plus stability issues which could be result of outdated 2.6.32 kernel e.g. unnecessary swapping overhead when big process moved from one group to another or even device hung.  

With Best Wishes,
Leonid


-----Original Message-----
From: ext Rik van Riel [mailto:riel@redhat.com] 
Sent: 04 January, 2012 22:18
To: Greg KH
Cc: Moiseichuk Leonid (Nokia-MP/Helsinki); linux-mm@kvack.org; linux-kernel@vger.kernel.org; cesarb@cesarb.net; kamezawa.hiroyu@jp.fujitsu.com; emunson@mgebm.net; penberg@kernel.org; aarcange@redhat.com; mel@csn.ul.ie; rientjes@google.com; dima@android.com; rebecca@android.com; san@google.com; akpm@linux-foundation.org; Jaaskelainen Vesa (Nokia-MP/Helsinki); Minchan Kim; KOSAKI Motohiro
Subject: Re: [PATCH 3.2.0-rc1 0/3] Used Memory Meter pseudo-device and related changes in MM

On 01/04/2012 02:56 PM, Greg KH wrote:

> How does this compare with the lowmemorykiller.c driver from the 
> android developers that is currently in the linux-next tree?

Also, the low memory notification that Kosaki-san has worked on, and which Minchan is looking at now.

We seem to have many mechanisms under development, all aimed at similar goals. I believe it would be good to agree on one mechanism that could solve multiple of these goals at once, instead of sticking a handful of different partial solutions in the kernel...

Exactly what is the problem you are trying to solve?

--
All rights reversed
N‹§²æìr¸›zǧu©ž²Æ {\b­†éì¹»\x1c®&Þ–)îÆi¢žØ^n‡r¶‰šŽŠÝ¢j$½§$¢¸\x05¢¹¨­è§~Š'.)îÄÃ,yèm¶ŸÿÃ\f%Š{±šj+ƒñb‚^[nö¢®×¥yÊ&Š{^®w­r\x16«ë"œ&§iÖ¬Š	á¶Ú\x7fþËh¦Ø^™ë^­Æ¿\x0e‰ízf¢•¨ky