On Wed, Aug 01, 2007 at 03:52:11PM -0700, Martin Bligh wrote: > > >And so forth. Initial forks will balance. If the children refuse to > >die, forks will continue to balance. If the parent starts seeing short > >lived children, fork()s will eventually start to stay local. > > Fork without exec is much more rare than without. Optimising for > 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. > the last time(s) this came up was to allow userspace to pass > a hint in if they wanted to fork and not exec. > > >I believe that this solved the pathological behavior we were seeing with > >shell scripts taking way longer on the larger, supposedly more powerful, > >platforms. > > > >Of course, that OS could migrate the equivalent of task structs and > >kernel stack [the old Unix user struct that was traditionally swappable, > >so fairly easy to migrate]. On Linux, all bets are off, once the > >scheduler starts migrating tasks away from the node that contains their > >task struct, ... [Remember Eric Focht's "NUMA Affine Scheduler" patch > >with it's "home node"?] > > Task migration doesn't work well at all without userspace hints. > SGI tried for ages (with IRIX) and failed. There's long discussions > of all of these things back in the days when we merged the original > NUMA scheduler in late 2.5 ... Task migration? Automatic memory migration you mean? I think it deserves another look regardless of what SGI could or could not do, and Lee and I are slowly getting things in place. We'll see what happens... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
