| |||||||||||||
Taming the OOM killerTaming the OOM killerPosted Feb 5, 2009 11:16 UTC (Thu) by iq-0 (subscriber, #36655)In reply to: Taming the OOM killer by epa Parent article: Taming the OOM killer
Since it is effectively the same as your all-in-one system call, since it would have to block till done to receive the necessary feedback. This way you can even implement a simple 'if exec(a) fails try exec(b) or otherwise flag error with (possibly program specific) meaningful data'...
I don't know if filehandle closing is allowed after vfork, but this would also be a great help to ensure the right file handles are passed (which would be a tedious operation or really complex/verbose in the case of a single fork-and-exec call).
(Log in to post comments)
Taming the OOM killer Posted Feb 5, 2009 14:08 UTC (Thu) by epa (subscriber, #39769) [Link] This way you can even implement a simple 'if exec(a) fails try exec(b) or otherwise flag error with (possibly program specific) meaningful data'...Oh sure, sometimes you will want to do something more complex like that. In these cases vfork() (as in classic BSD) doesn't work, because the child process is using memory belonging to the parent. The traditional fork() then exec() is best. But this is a small minority of the cases when an external command is run. And running an external command accounts for a large proportion of total fork()s. I'm just suggesting to make something more robust (avoiding the need to overcommit memory) for the common case.
Taming the OOM killer Posted Feb 5, 2009 17:03 UTC (Thu) by nix (subscriber, #2304) [Link]
I benchmarked this a while back. The common case is pipeline invocation,
for which you need at least dup()s and filehandle manipulation between fork() and exec(): and the nature of such manipulation differs for each invoker...
Taming the OOM killer Posted Feb 5, 2009 22:05 UTC (Thu) by epa (subscriber, #39769) [Link]
OK, I guess it's not as straightforward as I thought.
Perhaps another way to avoid the need for memory allocation would be to use a new vfork-like call (heck, it could even be called vfork) that has a fixed memory budget set as a matter of policy system-wide. So when you vfork(), the memory is set up as copy-on-write, but the child process has a budget of at most 1000 pages it can scribble on. That should be enough to set up the necessary file descriptors, but if it tries to dirty more than its allowance it is summarily killed.
That way, there is some upper limit to the amount of memory that needs to be allocated - when vfork()ing the kernel just needs to ensure 1000 free pages - and the kernel doesn't have to make a (possibly untrustworthy) promise that the whole process address space is available for normal use.
|
|||||||||||||