Re: [PATCH] Bug 3150: do not start useless unlinkd.

From: Henrik Nordström <henrik_at_henriknordstrom.net>
Date: Mon, 10 Oct 2011 09:09:39 +0200

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