| |||||||||||||
|
| |||||||||||||
Taming the OOM killerTaming the OOM killerPosted Feb 6, 2009 0:58 UTC (Fri) by martinfick (subscriber, #4455)In reply to: Taming the OOM killer by nix Parent article: Taming the OOM killer
Why when a process' stack is grown? In this case the process should fail (die?) just like when malloc would fail, but there should be no reason to upset other processes in the system!
(Log in to post comments)
Taming the OOM killer Posted Feb 6, 2009 1:26 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
with malloc you can check the return code to see if it failed or not and handle the error
how would you propose that programmers handle an error when they allocate a variable? (which is one way to grow the stack)
Taming the OOM killer Posted Feb 6, 2009 1:38 UTC (Fri) by brouhaha (subscriber, #1698) [Link] The process should get a segfault or equivalent signal. If there is a handler for the signal, but the handler can't be invoked due to lack of stack space, the process should be killed. If the mechanism to signal the process in a potential out-of-stack situation is too complex to be practically implemented in the kernel, then the process should be killed without attempting to signal it.At no point should the OOM killer become involved, because there is no reason to propagate the error outside the process (other than by another process noticing that the process in question has exited). A principle of reliable systems is confining the consequences of an error to the minimum area necessary, and killing some other randomly-selected (or even heuristically-selected) process violates that principle.
Taming the OOM killer Posted Feb 6, 2009 5:26 UTC (Fri) by njs (subscriber, #40338) [Link]
> At no point should the OOM killer become involved, because there is no reason to propagate the error outside the process (other than by another process noticing that the process in question has exited).
This makes sense on the surface, but memory being a shared resource means that everything is horribly coupled no matter what and life isn't that simple.
You have 2 gigs of memory.
Process 1 and process 2 are each using 50 megabytes of RAM.
Then Process 1 allocates another 1948 megabytes.
Then Process 2 attempts to grow its stack by 1 page, but there is no memory.
The reason the OOM exists is that it makes no sense to blame Process 2 for this situation. And if you did blame Process 2, then the system would still be hosed and a few minutes later you'd have to kill off Process 3, Process 4, etc., until you got lucky and hit Process 1.
Taming the OOM killer Posted Feb 7, 2009 17:52 UTC (Sat) by oak (guest, #2786) [Link]
Stack is actually yet another reason for overcommit. Current Linux
kernels map by default 8MB of stack for each thread (and usually threads use only something like 4-8KB of that). Without overcommit, process with 16 threads couldn't run in 128MB RAM, unless you change this limit. I think you can change it only from kernel source and it applies to all processes/threads in the system?
Taming the OOM killer Posted Feb 8, 2009 15:26 UTC (Sun) by nix (subscriber, #2304) [Link]
setrlimit (RLIMIT_STACK,...);
|
|
||||||||||||