Re: newidle balancing in NUMA domain?

[Ingo Molnar <mingo@elte.hu>]

* Mike Galbraith <efault@gmx.de> wrote:

> On Tue, 2009-11-24 at 09:40 +0100, Mike Galbraith wrote:
> > On Tue, 2009-11-24 at 07:53 +0100, Nick Piggin wrote:
> > > On Mon, Nov 23, 2009 at 04:53:37PM +0100, Mike Galbraith wrote:
> > > > 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?
> > > 
> > > No. Not for handing out tiny chunks of work and attempting to do
> > > them in parallel. There is this thing called Amdahl's law, and if
> > > you write a parallel program that wantonly uses the heaviest
> > > possible primitives in its serial sections, then it doesn't deserve
> > > to go fast.
> > 
> > OK by me.  A bit if idle time for kbuild is easily cured with telling
> > make to emit more jobs, so there's enough little jobs to go around.
> > 
> > If x264 is declared dainbramaged, that's fine with me too.
> 
> (P.S. I don't want to have to explain to users of any such thread 
> happy applications why they suck rocks under Linux though)

The 68% of speedup is pretty valid for your change and the workload isnt 
particularly odd beyond the fast creation rate of threads - but i'd not 
blame the app for that, Linux creates/destroys threads very fast. Your 
followup load-balancing fix got queued up in the scheduler tree for 
v2.6.33 ~two weeks ago:

  1b9508f: sched: Rate-limit newidle

certainly handles some of the NUMA pain. If not, numbers telling us the 
other story (and patches to extend 'perf bench sched' with matching 
testcases) would be helpful, i'm not seeing problems on my NUMA testbox.

1b9508f was certainly too late for 2.6.32, but since it appears to be 
fine it can be forwarded to stable@kernel.org so it makes it into 
2.6.32.1.

Thanks,

	Ingo