On Wed, Aug 01, 2007 at 03:52:11PM -0700, Martin Bligh wrote:And so forth. Initial forks will balance. If the children refuse toFork without exec is much more rare than without. Optimising for
die, forks will continue to balance. If the parent starts seeing short
lived children, fork()s will eventually start to stay local.
the uncommon case is the Wrong Thing to Do (tm). What we decided
It's only the wrong thing to do if it hurts the common case too
much. Considering we _already_ balance on exec, then adding another
balance on fork is not going to introduce some order of magnitude
problem -- at worst it would be 2x but it really isn't too slow
anyway (at least nobody complained when we added it).
One place where we found it helps is clone for threads.
If we didn't do such a bad job at keeping tasks together with their
local memory, then we might indeed reduce some of the balance-on-crap
and increase the aggressiveness of periodic balancing.
Considering we _already_ balance on fork/clone, I don't know what
your argument is against this patch is? Doing the balance earlier
and allocating more stuff on the local node is surely not a bad
idea.