[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4FC2362A.8080503@linux.intel.com>
Date: Sun, 27 May 2012 07:11:54 -0700
From: Arjan van de Ven <arjan@...ux.intel.com>
To: Mike Galbraith <efault@....de>
CC: Peter Zijlstra <peterz@...radead.org>,
lkml <linux-kernel@...r.kernel.org>,
Suresh Siddha <suresh.b.siddha@...el.com>,
Paul Turner <pjt@...gle.com>,
Andreas Herrmann <andreas.herrmann3@....com>
Subject: Re: [rfc][patch] select_idle_sibling() inducing bouncing on westmere
On 5/27/2012 2:17 AM, Mike Galbraith wrote:
> On Sat, 2012-05-26 at 10:27 +0200, Mike Galbraith wrote:
>> Hohum, back to finding out what happened to cpufreq.
>
> Answer: nothing.. in mainline.
>
> I test performance habitually, so just never noticed how bad ondemand
> sucks. In enterprise, I found the below, explaining why cores crank up
> fine there, but not in mainline. Somebody thumped ondemand properly on
> it's pointy head.
>
> But, check out the numbers below this, and you can see just how horrible
> bouncing is when you add governor latency _on top_ of it.
part of it is not ondemand, but cpufreq.
cpufreq forces you to schedule a kernel thread to change cpu
frequency... on the cpu that's already busy.
God knows what the scehduler then does in terms of load balancing.
(yes this is one of the things that will be fixed in the code that we
now have working internally, and we're now making sure does not regress)
btw, on modern Intel CPUs, where in Idle, you have a frequency of Zero,
regardless of what you ask for when you're running, and where an idle
cpu is clock gated.... the performance governor behaves almost the same
as ondemand in terms of power (due to the suckitude of ondemand)... but
much better performance.
--
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/
Powered by blists - more mailing lists