"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.
>
> > >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.
One fork attack I ran across (it was an "oopsie" by the user) worked as
follows (reduced to just the end result, not the original code):
while (1) {
if (fork() == 0) {
r = malloc(1024*1024);
for (i = 0; i < 1024*1024; i++) {
*r++ = 1;
}
}
}
This generates as many processes as possible, each one filling 1MB of memory.
In under 1/2 second all available process slots are in use, all processes
will expand as soon as the daemon kills one of them. When the parent process
fills it's memory it forks and does another 1MB.
The daemon may be able to catch the processes on a uniprocessor system -
especially if it runs at elevated priority. What happens on a SMP box?
One processor is spawning processes as fast, if not faster than the other
can kill them.
When this happend, we managed to stop the user (he couldn't keep up) it was
only because the fork limit quota allowed only 150 processes per user. We
put his job to sleep (it was in batch), then killed it. We couldn't even
keep up (there were 32 processors available at the time). We also promply
cut the number processors available to batch jobs from 32 to 30.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
-
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/
This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:34 EST