Subject: Re: [RFC] Enabling other oom schemes
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Robert Love <rml@tech9.net>
Cc: rusty@linux.co.intel.com, riel@conectiva.com.br,
       Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
In-Reply-To: <1063342229.700.240.camel@localhost>
References: <200309120219.h8C2JANc004514@penguin.co.intel.com>
	 <1063342229.700.240.camel@localhost>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1063363361.5379.3.camel@dhcp23.swansea.linux.org.uk>
Mime-Version: 1.0
Date: Fri, 12 Sep 2003 11:42:41 +0100
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 716
Lines: 16

On Gwe, 2003-09-12 at 05:50, Robert Love wrote:
> But I think its a lot more useful if we have alternative overcommit
> modes to use with it.
> 
> An oom_nop might be a good idea.  But some different policies, i.e. ones
> with more determinism but less smarts, are interesting.

The overcommit is currently handled by the security layer. It is
possible the oom callback should at least in part go that way so 
a security policy can for example kill only student tasks 8)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/