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.
signature.asc
Description: This is a digitally signed message part