On Tue, 2018-03-27 at 23:58 +0200, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
> 
> Rik reports that he sees an increase in CPU use in one benchmark
> due to commit 612f1a22f067 "cpuidle: poll_state: Add time limit to
> poll_idle()" that caused poll_idle() to call local_clock() in every
> iteration of the loop.  Utilization increase generally means more
> non-idle time with respect to total CPU time (on the average) which
> implies reduced CPU frequency.
> 
> Doug reports that limiting the rate of local_clock() invocations
> in there causes much less power to be drawn during a CPU-intensive
> parallel workload (with idle states 1 and 2 disabled to enforce more
> state 0 residency).
> 
> These two reports together suggest that executing local_clock() on
> multiple CPUs in parallel at a high rate may cause chips to get hot
> and trigger thermal/power limits on them to kick in, so reduce the
> rate of local_clock() invocations in poll_idle() to avoid that issue.
> 
> Fixes: 612f1a22f067 "cpuidle: poll_state: Add time limit to
> poll_idle()"
> Reported-by: Rik van Riel <r...@surriel.com>
> Reported-by: Doug Smythies <dsmyth...@telus.net>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>

Thanks Rafael!

Tested-by: Rik van Riel <r...@surriel.com>
Reviewed-by: Rik van Riel <r...@surriel.com>

-- 
All Rights Reversed.

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to