--------- 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/
This archive was generated by hypermail 2b29 : Sun Oct 15 2000 - 21:00:18 EST