Re: newidle balancing in NUMA domain?

[Mike Galbraith <efault@gmx.de>]

On Mon, 2009-11-23 at 16:29 +0100, Nick Piggin wrote:

> So basically about the least well performing or scalable possible
> software architecture. This is exactly the wrong thing to optimise
> for, guys.

Hm.  Isn't fork/exec our daily bread?

> The fact that you have to coax the scheduler into touching heaps
> more remote cachelines and vastly increasing the amount of inter
> node task migration should have been kind of a hint.
> 
> 
> > Fork balancing only works until all cpus are active. But once a core
> > goes idle it's left idle until we hit a general load-balance cycle.
> > Newidle helps because it picks up these threads from other cpus,
> > completing the current batch sooner, allowing the program to continue
> > with the next.
> > 
> > There's just not much you can do from the fork() side of things once
> > you've got them all running.
> 
> It sounds like allowing fork balancing to be more aggressive could
> definitely help.

It doesn't. Task which is _already_ forked, placed and waiting over
yonder can't do spit for getting this cpu active again without running
so he can phone home.  This isn't only observable with x264, it just
rubs our noses in it.  It is also quite observable in a kbuild.  What if
the waiter is your next fork?

	-Mike