Re: [PATCH] OOM killer API (was: [PATCH] VM fix for 2.4.0-test9 & OOM handler)

From: Andrew Pimlott (andrew@pimlott.ne.mediaone.net)
Date: Wed Oct 11 2000 - 11:48:54 EST


On Thu, Oct 12, 2000 at 01:58:49AM +1100, Matthew Hawkins wrote:
> On 2000-10-11 10:33:39 -0400, Bruce A. Locke wrote:
> >
> > Your making the deadly assumption that all applications behave themselves
> > exactly the same all the time. Oops... netscape decided to freak out and
> > take up all your memory... guess its the admins fault.
>
> Yep, for not setting appropriate resource limits.

No way should a desktop user be responsible for micro-managing the
resource usage of his applications. How can he decide what's
reasonable for Netscape to consume? Shouldn't Netscape be allowed
to take up most of memory, if it's the only major application and
the memory will improve its performance?

The only thing that knows what's right for Netscape is Netscape. If
Netscape were clever and kind, perhaps it would estimate what's
reasonable and set limits on itself, adjusting them from time to
time based on user behavior and environmental factors. But
Netscape's a pretty mature program, and it doesn't do this; it can
hardly be expected of the zillions of immature (and probably leaky)
applications a user might run.

So, we inevitably need an automated low-memory or out-of-memory
algorithm. I tend to think it may need to be more adjustable than
Rik's--people will be much more comfortable if they can say "spare
this simulation at all cost!" or "kill off one of these processes in
an emergency" or "this system has no business coming within 90% of
RAM+swap capacity, so start killing things at that point--oh, and
mail me". Some of this has no place in the kernel, obviously. But
Rik has a good start, and perhaps his work will be part of a more
complete solution.

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



This archive was generated by hypermail 2b29 : Sun Oct 15 2000 - 21:00:18 EST