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: 1436 bytes --]

On Mon, 2016-03-14 at 16:21 +0100, Rafael J. Wysocki wrote:
> On Mon, Mar 14, 2016 at 3:31 PM, Rik van Riel <riel@redhat.com>
> wrote:
> > 
> > Maybe something like 2x the exit latency (or target
> > residency?) of C1?
> 
> If the goal is to avoid entering C1 if the exit latency is too high,
> we should be checking the exit latency IMO.

I agree with that, but doesn't the current code already
do that?

The code currently checks against both the latency_req
and the expected sleep time. What is the rationale for
adding another latency to check against?

I am trying to understand what the goal is here, and
under what circumstances the logic in the main selection
loop needs to be overridden.

What is the main selection loop doing wrong?

When is it causing bad outcomes?

Is it causing other bad outcomes beyond C0/C1 selection?

Can we just ignore polling and always go to HLT, leaving
out this (somewhat kludgy feeling) part of the code?

If HLT is sometimes too slow on Atom, is it also too slow
for certain workloads on faster CPUs? (say 10Gbps ethernet?)

A lot of the logic (especially the load correction) in
menu.c was last fine tuned before several bugs in the
corresponding measuring code were fixed.

I don't understand your patch well enough to object to
it, but the "start the loop at poll instead of HLT"
logic is becoming rather convoluted...

-- 
All Rights Reversed.


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