Re: SKL BOOT FAILURE unless idle=nomwait (was Re: PROBLEM: Cpufreq constantly keeps frequency at maximum on 4.5-rc4)

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

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

On Wed, 2016-03-16 at 16:05 +0100, Rafael J. Wysocki wrote:
> On Wed, Mar 16, 2016 at 3:46 PM, Rik van Riel <riel@redhat.com>
> wrote:
> > 
> > On Wed, 2016-03-16 at 15:14 +0100, Rafael J. Wysocki wrote:
> > > 
> > > On Wed, Mar 16, 2016 at 3:01 PM, Rik van Riel <riel@redhat.com>
> > > wrote:
> > > > 
> > > > 
> > > > On the other hand, being more aggressive about C1 allows
> > > > other cores to run at higher frequencies...
> > > Good point.
> > > 
> > > We need to decide, though.
> > > 
> > > Do we generally want to use more polling or more C1?
> > I can see five distinct data points for decision making:
> > 
> > 1) data->next_timer_us where we know for sure the sleep
> >    interval will be less than C1 latency -> poll
> Almost right, modulo my previous comment: that should be the sum of
> C1
> exit latency and C1 target residency.

Doesn't the residency include the exit latency?

After all, we subtract the exit latency from the
measured residency time in menu_update.

> > Would you like me to write a patch to take the user
> > configured latency_req into account, separate out
> > the predicted_us and typical_interval, and test whether
> > to poll against the smaller of next_timer_us, latency_req,
> > and the typical_interval, while we continue to use the
> > predicted_us as is in the main selection loop?
> Yes, please.

Will do.

-- 
All Rights Reversed.


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