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 Tue, 21 Mar 2000, Jesse Pollard wrote:

> "Richard B. Johnson" <root@chaos.analogic.com>:
> > 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.
>
> But what about some of those fork bombs? - they may fork 10-20 processes
> and all start touching memory simultaneously. The daemon doesn't have
> any information on the new processes, It hasn't had time to even read
> the proc table.

[SNIPPED]

Once these fork bombs start to touch swap, they have to sleep. This
makes CPU time available for a task that already has all the virtual
RAM it needs.

You don't have to make a complete daemon to test. Just launch a task
that sleeps for 60 seconds, then kills the PID that you give it.

Start your fork bomb with & so you get its PID from the shell,
then start your daemon. Remember, you only have the parent's PID which
is a worse case because it takes a long time for the kids to get killed.
Since this is a proof-of-concept, and we want the kids to get killed when
the parent expires, you do not do setsid() for each of the kids.
We all know how to cheat to make such a simple daemon worthless.
I just want to show that the daemon has plenty of resources once
the bomb starts to swap.

The machine will get slow and 'hang'. After 60 seconds, it will
recover when the daemon kills the parent and the children start to
die.


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.031 / U:0.148 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site