From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail203.messagelabs.com (mail203.messagelabs.com [216.82.254.243]) by kanga.kvack.org (Postfix) with SMTP id 25C486B0047 for ; Sun, 7 Feb 2010 17:58:04 -0500 (EST) From: Oliver Neukum Subject: Re: Improving OOM killer Date: Fri, 5 Feb 2010 08:35:30 +0100 References: <201002012302.37380.l.lunak@suse.cz> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201002050835.30550.oliver@neukum.org> Sender: owner-linux-mm@kvack.org To: David Rientjes Cc: Jiri Kosina , Lubos Lunak , Balbir Singh , Rik van Riel , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , KOSAKI Motohiro , Nick Piggin List-ID: Am Donnerstag, 4. Februar 2010 22:39:08 schrieb David Rientjes: > > If we really want kernel to detect forkbombs (*), we'd have to establish > > completely separate infrastructure for that (with its own knobs for tuning > > and possibilities of disabling it completely). > > > > That's what we're trying to do, we can look at the shear number of > children that the parent has forked and check for it to be over a certain > "forkbombing threshold" (which, yes, can be tuned from userspace), the > uptime of those children, their resident set size, etc., to attempt to > find a sane heuristic that penalizes them. Wouldn't it be saner to have a selection by user, so that users that are over the overcommit limit are targeted? Regards Oliver -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org