linux-kernel - Re: newidle balancing in NUMA domain?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 24 Nov 2009 10:11:24 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Mike Galbraith <efault@....de>
Cc:	Nick Piggin <npiggin@...e.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: newidle balancing in NUMA domain?


* Mike Galbraith <efault@....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@...nel.org so it makes it into 
2.6.32.1.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/