linux-kernel - Re: Improving OOM killer

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: <alpine.DEB.2.00.1002101427490.29718@chino.kir.corp.google.com>
Date:	Wed, 10 Feb 2010 14:31:47 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
cc:	Rik van Riel <riel@...hat.com>, Lubos Lunak <l.lunak@...e.cz>,
	Balbir Singh <balbir@...ux.vnet.ibm.com>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Nick Piggin <npiggin@...e.de>, Jiri Kosina <jkosina@...e.cz>
Subject: Re: Improving OOM killer

On Wed, 10 Feb 2010, Alan Cox wrote:

> One of the problems with picking on tasks that fork a lot is that
> describes apache perfectly. So a high loaded apache will get shot over a
> rapid memory eating cgi script.
> 

With my rewrite, the oom killer would not select apache but rather the 
child with a seperate address space that is consuming the most amount of 
allowed memory and only when a configurable number of such children (1000 
by default) have not had any runtime.  My heuristic is only meant to 
slightly penalize such tasks so that they can be distinguished from oom 
kill from other parents with comparable memory usage.  Enforcing a strict 
forkbomb policy is out of the scope of the oom killer, though, so no 
attempt was made.

> Any heuristic is going to be iffy - but that isn't IMHO a good one to
> work from. If anything "who allocated lots of RAM recently" may be a
> better guide but we don't keep stats for that.
> 

That's what my heuristic basically does, if a parent is identified as a 
forkbomb, then it is only penalized by averaging the memory consumption of 
those children and then multiplying it by the same number of times the 
configurable forkbomb threshold was reached.
--
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/