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

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

2) latency_req as configured by the user, if this is
   smaller than C1
latency we need poll  (we currently
   get this wrong)

3) interval determined by get_typical_interval, this we
   may know with a higher confidence value, and choosing
   poll may actually be appropriate

4) data->predicted_us corrected only by bucket correction
   factor - this is a gamble, so we probably want C1,
   even if data->predicted_us is low

5) interactivity_req, which is data->predicted_us
   divided by a load factor - we should probably ignore
   that for poll since it is way too aggressive, and
   stick to C1 and deeper for this factor

Does the above make sense?

Currently the code merges (3) and (4) into the same
value before making a comparison, and neglects to take
(2) into account at all when deciding whether to poll.

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?

-- 
All Rights Reversed.


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