[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1338129122.7400.45.camel@marge.simpson.net>
Date: Sun, 27 May 2012 16:32:02 +0200
From: Mike Galbraith <efault@....de>
To: Arjan van de Ven <arjan@...ux.intel.com>
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 Sun, 2012-05-27 at 16:29 +0200, Mike Galbraith wrote:
> On Sun, 2012-05-27 at 07:11 -0700, Arjan van de Ven wrote:
> > 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.
(and yeah, I am lumping ondemand and cpufreq together, which is wrong)
--
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