On Sun, 19 Mar 2000, Jesse Pollard wrote:
>On Sun, 19 Mar 2000, James Sutherland wrote:
>>On Sat, 18 Mar 2000 08:31:58 -0600, you wrote:
>>
>>> Users (and processes) will get an Out-Of-Resource
>>> errors which the users can deal with.
>>
>>In practice, they usually just die.
>
>The user still gets the choice.
No, this can't be allowed. What happens in the case of:
OOM -> signal processes Out of Resources
all processes decide to ignore the signal
Once we are OOM, you can't give user-space any choices.
Repeat after me:
You can not solve the OOM problem in user space.
You can not solve the OOM problem without killing processes.
Resource limits are not a good solution to the OOM problem.
I don't like resource limits. Using resource limits is similar to not
having memory overcommit -- you waste a lot of system resources "just in
case", the kernel needs to do a lot more accounting, and it's just
horribly inefficient.
>>> If the proper resource allocation were given then usrs running wild
>>> memory allocators would not be able to crash the system by causing
>>> init to die.
>>They shouldn't be able to anyway - Rik's patch should ensure that init
>>will always survive, even if every other process on the box is hosed.
>>(Of course, if init was the malfunctioning process to begin with...)
If init malfunctions, you're hosed no matter what.
>>>All else is a matter of implementation.
>>
>>The core problem remains. You, the user, have a finite amount of
>>memory available to you, however that limit is defined. Once you run
>>out, your processes will start dying.
But that's not the problem! That's the way things have to be. You can't
use more resources than there are available.
>Yes - ME THE USER. I should not be able to cause the SYSTEM a problem.
>I should not be able to cause OTHER users a problem.
Ahh, no! You can only do this by setting up horribly restrictive quotas
and effectively removing overcommit, which is terribly wasteful!
>>We need per-user resource limits, ideally - until then, everything is
>>done with process granularity instead. This is a shortcoming we all
>>know about already, but not one that is likely to be fixed any time
>>soon.
>
>That is possibly why the OOM complaints will not go away.
Well, my OOM complaints stem from the fact that right now OOM situations
are functionally equivalent to crashing the machine.
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:28 EST