Re: [PATCH] OOM killer API (was: [PATCH] VM fix for 2.4.0-test9 & OOM handler)

From: Jesse Pollard (
Date: Wed Oct 11 2000 - 10:16:42 EST

--------- Received message begins Here ---------

> On 2000-10-11 09:45:30 -0500, Jesse Pollard wrote:
> > Until user memory resource quotas are included in the kernel, there will be
> > nothing else that can be done. Even with resource quotas, if the total of
> > active users exceeds the resource then the same/equivalent situation occurs.
> RLIMIT_MEMLOCK, RLIMIT_AS et al is a null op?
> If so, I wish to register a complaint ;-)

Not exactly. As I have seen it, each process gets a copy of these limits.
A single process cannot exceed the limit, but the sum of all processes

One of the problems is cause by COW:

given trivially small limits (1 MB)

  The first process allocates and initializes up to one MB, then forks.
  The second process begins updating data - .5MB. Neither process exceeds
  the limits, but the sum is now 1.5MB. If this is repeated enough, then
  the system can go OOM, with none of the processes at or over the limits

Another problem occurs on multi-user servers. Each user logs in and
gets "reasonable" rlimit values - each user uses one medium sized
process. If the #users * rlimits exceeds the system capacity then OOM
could occur, and still none may have exceeded the rlimit.

I've always treated rlimit values as "suggestions" to the user process
to aid in debugging. (this is more applicable to the ulimits though).
The users process will not exeed the value, and when they do it is a
strong suggestion that a bug may be present. (I first saw this with a
leakey X server.)

There have been some patches (the beancounter stuff) that does relate
to resource control, but a more integrated resource accounting will make
it work better. I do believe it should be available as an option, especially
for multi-user servers, clusters, and other large systems.

It isn't that usefull on single user workstations.

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 : Sun Oct 15 2000 - 21:00:18 EST