lkml.org 
[lkml]   [1999]   [Jul]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Memory hogs
Date
From
Claus Fischer wrote:
> Werner Almesberger wrote:
> : Hermann Schichl wrote:
> : > I think it would be great if OOM handling would be
> : > configurable (either kernel compile time or /proc interface)
> :
> : Better yet, have a device or proc file that becomes readable in this case.
> : Then you can have a user-space demon to implement whatever policy you
> : like.
> : The demon can mlock its pages, so it should be reasonably safe from
> : causing
> : an OOM itself. Writing to that device/proc file could set the threshold
> : for
> : when OOM recovery is necessary.
> :
> : Reasonable policies may include enabling overflow swap space, SIGSTOP'ing
> : all processes above a certain size/growth rate, paging the administrator,
> : and opening a shell on the system console.
> :
> : - Werner
>
>
> I'm not against user-space solutions as a supplementary measure.
> I'm however totally against saying: "We'll find a userspace solution,
> so it's OK for the kernel not to do anything intelligent."
>
> Not for Linux.
>
> This is the OS that I have carefully chosen for my desktop machine;
> it hasn't been imposed on me by my managers, and I want it to shine
> even where others spread darkness.
>
Same here. Though, I somewhat imposed it on the managers.
>
> If you have a good userspace solution, this is not the discussion
> for you. Go ahead and implement it and you're saved. Stop reading.
> You don't care for the kernel OOM situation any more. [1]
>
This is not quite correct since it needs a proper kernel interface
to construct a useful user space solution. Werner, IMHO, correctly
pointed out that the FANCY solution stuff and the configurable
parts should go to user space. The kernel itself should provide
a reasonable default action which is stateless, simple, fast and small.
I think we all agree that the kernel has to take proper measures
to keep the most important processes running.
>
> But if you use Linux in the way computers are used by real men: to
> further the progress of mankind by performing the most complicated
> and memory-intensive simulations, they you'll certainly agree that
> the Linux kernel should do better than falling in with the crowd
> of "well you can't just do that to our operating system" designs.
>
That is the point. IF you are doing the most complicated and
memory-intensive simulations then you want to GUARANTEE that this one
does not die after five days of computing time.
>
> The kernel should not let the machine die and become unusable. It has
> to guarantee the bare survival, which includes: integrity of init,
> rlogind, etc. On my desktop box, it had better let X survive as well,
>
Yes, and my simulation if ever possible. And if the simulation is the
problem, I probably would prefer to stop the process, decide to add some
more swap space if I have some free hard disk space and continue the process.
>
> if it wants to be regarded a strategic ally (remember, the goal is
> saving mankind :--)
>

To summarize my opinion:
We need proper kernel handling of OOM situations it should be simple,
stateless, and failsafe.
In addition we should have a nice interface (device, proc, ...)
which makes it possible to construct a user space solution of
NEAR OOM situations which is configurable (fancy and shining :) if
necessary) to make it suitable for (almost) all needs out there.

Hermann



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

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:0.039 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site