sön 2011-10-09 klockan 16:34 +1300 skrev Amos Jeffries:
> We still have and occasionally hit the same old OOM ceiling on fork()
> with multi-GB RAM caches, but its a noticeably less common complaint now.
And the workaround is as before to make sure to have plenty of swap
space available, preventing OOM, or alternatively enable memory usage
overcommit.
Note: The swap only needs to exist to temporarily enable the virtual
memory to be reserved, it's not actually swapped to by the fork+exec.
Note 2: Linux by default enables a quite significant memory usage
overcommit ratio, hiding most of this fork() virtual memory requirement
madness from the user.
Using vfork() has too many pitfalls to be considered imho. It's a broken
by design interface. Actually fork+exec is also a broken interface but
at least somewhat workable (but we don't do it correctly in error cases)
A better alternative is to use posix_spawn() where available. Maybe with
fallback on fork+exec if there is any systems we need to support which
lacks posix_spawn() support today. This path also means dropping the
helper communication channel validation, just as using vfork does.
Basically the viable choices boils down to
a) Keep existing fork+exec code, with it's benefits (validation, error
reporting etc) and drawbacks (virtual memory explosions).
b) Drop helper channel validation and switch to using posix_spawn()
solving the virtual memory explosions.
Regards
Henrik
Received on Mon Oct 10 2011 - 07:09:45 MDT
This archive was generated by hypermail 2.2.0 : Mon Oct 10 2011 - 12:00:07 MDT