| |||||||||||||
Ghosts of Unix past, part 4: High-maintenance designsGhosts of Unix past, part 4: High-maintenance designsPosted Dec 6, 2010 10:58 UTC (Mon) by pbonzini (subscriber, #60935)In reply to: Ghosts of Unix past, part 4: High-maintenance designs by nix Parent article: Ghosts of Unix past, part 4: High-maintenance designs
no benefit over fork()/exec() at all (except on tiny non-MMU systems, which can theoretically implement spawn*() but not fork()/exec()Actually, if the parent has a large RSS it is quite common to see major performance improvements with vfork() over fork(). And given how hacky vfork() is, I'd really be happy to pay the price of spawn()'s inflexibility. fork() should be treated like a relic of when parallelism was achieved using processes rather than threads, IMO.
(Log in to post comments)
Ghosts of Unix past, part 4: High-maintenance designs Posted Dec 6, 2010 11:31 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
does this vfork advantage still exist (i.e., is it measurable) when the host OS does Copy On Write for the fork instead of actually copying all ram?
yes, the page tables still get modified twice, but is this measurable on modern hardware?
Ghosts of Unix past, part 4: High-maintenance designs Posted Dec 6, 2010 11:58 UTC (Mon) by pbonzini (subscriber, #60935) [Link]
Yes, I've seen forking take 60% of CPU (that was forking 4 child processes per second from a +2 GB process). Using fork to vfork, or equivalently switching to posix_spawn, brought it down to 3-4%.
|
|||||||||||||