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.
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.
When OOM the kernel has to kill something. The trick is for the kernel to
kill tasks that are considered "less important". Don't kill init, X
server, syslogd, whatever. Some of this policy could be set by a userspace
daemon.
This is completely independent of overcommit or rlimits (which can cause
the OOM behavior to happen more often, though in more predictable and
perhaps less drastic fashion).
I'm a scientific app programmer, not a system programmer... but I'll try
to code up a simple daemon in the next couple days that works in
conjunction with a modified version of Rik van Riel's patch.
Dave
David Whysong dwhysong@physics.ucsb.edu
Astrophysics graduate student University of California, Santa Barbara
My public PGP keys are on my web page - http://www.physics.ucsb.edu/~dwhysong
DSS PGP Key 0x903F5BD6 : FE78 91FE 4508 106F 7C88 1706 B792 6995 903F 5BD6
D-H PGP key 0x5DAB0F91 : BC33 0F36 FCCD E72C 441F 663A 72ED 7FB7 5DAB 0F91
-
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:31 EST