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

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]

Message-ID: <84FF21A720B0874AA94B46D76DB98269045549DF@008-AM1MPN1-003.mgdnok.nokia.com>
Date:	Mon, 9 Jan 2012 08:27:52 +0000
From:	<leonid.moiseichuk@...ia.com>
To:	<rientjes@...gle.com>
CC:	<gregkh@...e.de>, <penberg@...nel.org>, <linux-mm@...ck.org>,
	<linux-kernel@...r.kernel.org>, <cesarb@...arb.net>,
	<kamezawa.hiroyu@...fujitsu.com>, <emunson@...bm.net>,
	<aarcange@...hat.com>, <riel@...hat.com>, <mel@....ul.ie>,
	<dima@...roid.com>, <rebecca@...roid.com>, <san@...gle.com>,
	<akpm@...ux-foundation.org>, <vesa.jaaskelainen@...ia.com>
Subject: RE: [PATCH 3.2.0-rc1 0/3] Used Memory Meter pseudo-device and
 related changes in MM

> -----Original Message-----
> From: ext David Rientjes [mailto:rientjes@...gle.com]
> Sent: 06 January, 2012 01:10

> If you can accept the overhead of the memory controller (increase in
> kernel text size and amount of metadata for page_cgroup), then you can
> already do this with a combination of memory thresholds with
> cgroup.event_control and disabling of the oom killer entirely with
> memory.oom_control.  You can also get notified when the oom killer is
> triggered by using eventfd(2) on memory.oom_control even though it's
> disabled in the kernel.  Then, the userspace task attached to that control
> file can send signals to applications to free their memory or, in the
> worst case, choose to kill an application but have all that policy be
> implemented in userspace.

We invested in memcg notification (Kiryl Shutsemau's patches) and use the similar approach in n9 already (see libmemnotifyqt on gitorious).
Unfortunately it is produces number of side effects which are related how memcg handled application injection/removal from/to group.
So I like to try another approach.

> We actually have extended that internally to have an oom killer delay,
> i.e. a specific amount of time must pass for userspace to react to the oom
...
> handled the event").  Those patches were posted on linux-mm several
> months
> ago but never merged upstream.  You should be able to use the same
> concept
> apart from the memory controller and implement it generically.

Yep. But in n9 concept OOMing some application is acceptable, so I do not see such changes as very suitable.

> You also presented this as an alternative for "embedded or small" users so
> I wasn't aware that using the memory controller was an acceptable solution
> given its overhead.

Overhead, by the way, fully acceptable and I think in never kernels (3.x) situation will be much better.
But memcg has from my point principal problems for case when you cgroup application set is updated when application foregrounded/backgrounded, unfortunately that is how n900 and n9 software designed.

Best Wishes,
Leonid
--
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/