>> > How the hell can that have any effect on non-threaded workloads? Perhaps>> > some part of kernel compile *is* multi-threaded. It does seem to get >> >> make(1) with vfork(2) perhaps?> > Very likely. And in the vfork() case it is definitely WRONG to try to> reschedule (either threads _or_ processes), since the parent is going to> go to sleep real soon now.> > I think this code:> > if (clone_flags & CLONE_VM)> wake_up_forked_thread(p);> else> wake_up_forked_process(p);> > is just wrong, and it should be replaced with> > wake_up_new_process(p, clone_flags);> > and then "wake_up_new_process()" can do the right thing, which is > basically:> > if (clone_flags & CLONE_VFORK)> synchronous wakeup, same as pipe-will-block case> else if (clone_flags & CLONE_VM)> thread-wakeup-case> else> process-wakeup-case> > No?

Looks much better ... but I'd still dispute whether we need to throw non-vfork threads cross node by default. I'd suggest that's disabledby default, and is either enabled by a global userspace option, or aper-process one (or the option of both). Most thing (except benchmarks)simply don't want this in real life ...