lkml.org 
[lkml]   [2000]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Some questions about linux kernel.
On Mon, 20 Mar 2000, Jesse Pollard wrote:

> On Mon, 20 Mar 2000, David Whysong wrote:
> >On Mon, 20 Mar 2000, Richard B. Johnson wrote:
> >
> >>The only solution to an out-of-memory condition is to never run
> >>out of memory.
> >
> >Yes!
> >
> >>The place where all of the system information is known is in "user
> >>space". The kernel readily "knows" stuff about the current process, but
> >>retrieving information about other tasks in a page-fault handler would
> >>result in an extremely poor performing machine. A user-space daemon can
> >>acquire information about all the tasks, can detect runaway tasks, can
> >>safeguard special tasks like Web Servers that haven't gone crazy, and
> >>can watch for performance hurting rogue programs.
> >>
> >>Such a program, if properly designed, is the solution to such
> >>out-of-memory conditions.
> >
> >No! Or perhaps it depends on what you want this user-space daemon to do.
> >

The rogue program would have to _touch_ all the pages in the system during
a single time-slice. Once it started using pages in the backing-store,
this would be impossible because disk I/O sleeps.

The monitor daemon only has to work as fast as a person. Try it from a
logged-in shell. You can wait until your swap-file disk-drive starts
thrashing then have plenty of resources available to kill the task as
long as you know ahead of time what its pid was. It is presumed that
the daemon will keep track of heavy-breathers and certainly know who's
the blame before an OOM condition occurs.

> >Once you reach the OOM condition, this program can not reliably run. And I
> >doubt that a user-space daemon could prevent OOM from happening on a time
> >sharing system, since a malicious (or buggy) program could try to use all
> >memory during a single timeslice.

No. As long as you have backing store (swap file), you will have plenty
of CPU available for the monitor program. The monitor program has to
be designed properly. It has to allocate its memory upon startup.
It has to use runtime function calls to handle tasks, not forking and
exec. For the most part, it sits there reading the /proc file-system.


Cheers,
Dick Johnson

Penguin : Linux version 2.3.41 on an i686 machine (800.63 BogoMips).


-
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:57    [W:0.746 / U:0.416 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site