Re: [regression] cross core scheduling frequency drop bisected to 0c313cb20732

[Rik van Riel <riel@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1591 bytes --]

On Sun, 2016-04-10 at 17:39 +0200, Mike Galbraith wrote:
> On Sat, 2016-04-09 at 14:31 +0200, Rafael J. Wysocki wrote:
> > 
> > On Sat, Apr 9, 2016 at 1:07 PM, Peter Zijlstra <peterz@infradead.or
> > g>
> > wrote:
> > > 
> > > On Fri, Apr 08, 2016 at 10:59:59PM +0200, Rafael J. Wysocki
> > > wrote:
> > > > 
> > > > On Friday, April 08, 2016 08:50:54 AM Mike Galbraith wrote:
> > > > > 
> > > > > On Fri, 2016-04-08 at 08:45 +0200, Peter Zijlstra wrote:
> > > > > 
> > > > > > 
> > > > > > Cute, I thought you used governor=performance for your
> > > > > > runs?
> > > > > I do, and those numbers are with it thus set.
> > > > Well, this is a trade-off.
> > > > 
> > > > 4.5 introduced a power regression here so this one goes back to
> > > > the previous
> > > > state of things.
> > > Just for my elucidation; how can gov=performance have a 'power'
> > > regression?
> > Because of what is used as the "default" idle state most of the
> > time.
> > 
> > C1 was used before 4.5 and that changed to polling in 4.5.
> Should the default idle state not then be governor dependent?  When I
> set gov=performance, I'm expecting box to go just as fast as it can
> go
> without melting.  Does polling risk CPU -> lava conversion?

Current CPUs can only have some cores run at full speed
(turbo mode) if other cores are idling and/or running at
lower speeds.

It may be time to stop pretending that gov=performance
actually results in better performance on current CPUs,
since it may inhibit entire levels of turbo mode.

-- 
All Rights Reversed.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]