Messages in this thread |  | | Date | Wed, 11 Oct 2000 10:16:42 -0500 (CDT) | From | Jesse Pollard <> | Subject | Re: [PATCH] OOM killer API (was: [PATCH] VM fix for 2.4.0-test9 & OOM handler) |
| |
--------- 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. > > So setrlimit() with RLIMIT_DATA, RLIMIT_STACK, RLIMIT_RSS, > 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 can.
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 set.
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 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.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |