Re: Some questions about linux kernel.

From: Jesse Pollard (
Date: Mon Mar 20 2000 - 23:07:48 EST

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.
>>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

By the time the userspace daemon runs it is too late.

The kernel must do the bookkeeping for the resource allocation. It must
be able to decrement from the users quota what is being allocated by the
various allocation methods - fork, exec, sbrk, stack page fault, COW.

The kernel can enforce the limit, but it cannot determine what the limit
should be. This is the place for the userspace daemon.

On some systems, the quotas are staticly set by administration, and loaded
into the kernel on login (or cron/batch). If the quotas to be set are
not available (determined by the userspace daemon) then the user should
not be logged in (or cron/batch job not started).

It may be possible for the userspace daemon to be able to carry out
adjustments - If the policy is that from 8-5 all logins/cron/batch may
have the quota set by administration until N logins are active. No more
may be allowed. If the policy between 5-8 (over night) is that only
5 logins are allowed, then the quota set by administration might be
expanded by some amount - this is a basis for batch schecdules at
night where the batch queues are allowed a totaly independant quota
limits from the users interactive limits.

>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).

It is a way to prevent OOM from occuring at the system level.

>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.

Watch out for the kernel level accounting that is needed.

Jesse I Pollard, II

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
Please read the FAQ at

This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:31 EST