linux-kernel - Re: [RFC] [PATCH] Cgroup based OOM killer controller

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: <20090127134559.GB18119@ioremap.net>
Date:	Tue, 27 Jan 2009 16:45:59 +0300
From:	Evgeniy Polyakov <zbr@...emap.net>
To:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
Cc:	David Rientjes <rientjes@...gle.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>, balbir@...ux.vnet.ibm.com,
	Nikanth Karthikesan <knikanth@...e.de>,
	containers@...ts.linux-foundation.org,
	linux-kernel@...r.kernel.org,
	Torvalds <torvalds@...ux-foundation.org>,
	Arve Hj?nnev?g <arve@...roid.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Chris Snook <csnook@...hat.com>,
	Paul Menage <menage@...gle.com>
Subject: Re: [RFC] [PATCH] Cgroup based OOM killer controller

Hi.

On Tue, Jan 27, 2009 at 07:40:58PM +0900, KOSAKI Motohiro (kosaki.motohiro@...fujitsu.com) wrote:
> I'd like to respect your requiremnt. but I also would like to know
> why you like deterministic hierarchy oom than notification.
> 
> I think one of problem is, current patch description is a bit poor
> and don't describe from administrator view.

Notification of the memory state is by no means a great idea.
Any process which cares about the system state can register and make
some decisions based on the memory state. But if it fails to update to
the current situation, the main oom-killer has to enter the scene and
make a progress on the system behaviour.

As I wrote multiple times there may be a quite trivial situation, when
process will not be able to make progress (it will not be able to free
some data even if its memory notification callback is invoked in some
cases), so we just can not rely on that. After all there may be no
processes with given notifications registered, so we should be able to
tune main oom-killer, which is another story compared to the
/dev/mem_notify discussion.

Having some special application which will monitor /dev/mem_notify and
kill processes based on its own hueristics is a good idea, but when it
fails to do its work (or does not exist) system has to have ability to
make a progress and invoke a main oom-killer.

-- 
	Evgeniy Polyakov
--
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/