On Sun, 19 Mar 2000, Olaf Weber wrote:
>Jesse Pollard writes:
>> On Fri, 17 Mar 2000, Olaf Weber wrote:
>
>> One thing I thought of that would help reduce the effect of
>> fork/exec sequence on the reservation - If the fork only reserved
>> say 5-10 pages - then if the new process exceeded this reserve then
>> entire amount should be reserved. This would reduce the peak
>> reservation in the case of a fork followed by an exec. This delayed
>> reservation should give nearly the same peak as the current method,
>> and protect against the worst case.
>
>It seems an interesting hack^H^H^H^Htechnique. The parent process
>should of course be aware that a fork can almost immediately be
>followed by the child dying thanks to OOM. Then again, that's true
>now too, so if the parent cannot cope, it is buggy today.
It is a bit of a hack. I was trying to reduce the reprogramming needed
if something like vfork or fork with a flag that made it equivalent to
vfork.
The second part about the parent expecting an OOM terminated child
is almost a given (and is buggy). The expected OOM termination would
usually be to issue an error message about the condition rather than
"can't execute yyyy", which implies that it is the exec that failed
instead of memory allocation.
The biggest problem I have been able to identify is that when
the unreserved memory is copied via COW, either the parent OR child may
be doing the write. The only alternative is that the memory be marked
COW for the child only. This however might affect those long running
processes that fork just for the purposes of saving the "current" state
of a large array; this case really does call for COW on both parent
and child - as well as full reservation on fork.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@cats-chateau.net
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.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:26 EST