Messages in this thread | | | From | "Rafael J. Wysocki" <> | Date | Tue, 27 Mar 2018 18:42:57 +0200 | Subject | Re: [PATCH v2] cpuidle: poll_state: Add time limit to poll_idle() |
| |
On Thu, Mar 22, 2018 at 5:32 PM, Rik van Riel <riel@surriel.com> wrote: > On Wed, 2018-03-14 at 13:04 +0100, Peter Zijlstra wrote: > >> On x86 we don't have to use that time_check_counter thing, >> sched_clock() >> is really cheap, not sure if it makes sense on other platforms. > > Are you sure? I saw a 5-10% increase in CPU use, > for a constant query rate to a memcache style > workload, with v3 of this patch.
I think I know what's going on.
Increased utilization with the same amount of work per time unit (and I guess that's the case given the lack of specific information about the workload) means more non-idle time with respect to total time and that implies reduced frequency (eg. less turbo).
Now, combine that with the Doug's observation that limiting the rate of local_clock() invocations in the poll_idle() loop reduces power draw during experiments on his system significantly and with the other one that in both cases local_lock() ends up being rdtsc() (most likely).
What this implies to me is that invoking rdtsc() at a high rate on multiple logical CPUs in parallel causes chips to get hot. Actually that may be so hot that they hit power/thremal (eg. RAPL) limits and get their frequency reduced as a result.
Limiting the rate of local_clock() invocations obviously avoids this issue.
| |