Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 30 Mar 2001 09:50:35 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 30 Mar 2001 09:50:26 -0500 Received: from [207.246.91.243] ([207.246.91.243]:1806 "HELO thor") by vger.kernel.org with SMTP id ; Fri, 30 Mar 2001 09:50:12 -0500 Date: Fri, 30 Mar 2001 09:48:18 -0500 From: "J. Scott Kasten" To: Michael Peddemors cc: David Konerding , linux-kernel@vger.kernel.org Subject: Re: OOM killer??? In-Reply-To: <20010330024815Z130448-406+5643@vger.kernel.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Just to throw my own observations into the war, I have to agree with David K. here. This needs to be some sort of module and/or interface. Get the policy into a replaceable user space module. One of the hot areas for the kernel right now is for embedded systems. They need an entirely different strategy than for a desk top. I'm working on such a thing now were we don't even have an enabled swap space and the OOM is causing us no end of trouble as we start dipping below 1MB "free" system memory. On 29 Mar 2001, Michael Peddemors wrote: > Looking over the last few weeks of postings, there are just WAY to many > conflicting ways that people want the OOM to work.. Although an > incredible amount of good work has gone into this, people are definetely > not happy about the benifits of OOM ... About 10 different approaches > are being made to change the rule based systems pertaining to WHEN the > OOM will fire, but in the end, still not everyone will be happy.. > On 29 Mar 2001 07:41:44 -0800, David Konerding wrote: > > > Now, if you're going to implement OOM, when it is absolutely necessary, at the very > > least, move the policy implementation out of the kernel. One of the general > > philosophies of Linux has been to move policy out of the kernel. In this case, you'd > > just have a root owned process with locked pages that can't be pre-empted, which > > implemented the policy. You'll never come up with an OOM policy that will fit > > everybody's needs unless it can be tuned for particular system's usage, and it's > > going to be far easier to come up with that policy if it's not in the kernel. - 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/