On 2016-09-13 04:50, Dietmar Eggemann wrote:
On 03/09/16 00:27, markivx@codeaurora.org wrote:
From: Vikram Mulukutla markivx@codeaurora.org
Actual frequency on X86 may be a function of the number of non-idle CPUs, the highest frequency amongst the cpufreq policies corresponding to the CPUs, and whether a turbo-boost frequency has been selected. For example, if cpu0 has voted for 2GHz and cpu1 for 1GHz, cpu1 can also run at 2GHz for as long as cpu0 is not idle.
This can result in somewhat inaccurate load tracking when a load statistic needs to be frequency invariant. To address this, calculate the current frequency on supported Intel X86 machines using the PMC counters. As far as I can tell, these counters can't be read by a remote CPU, and IPIs would be too expensive, so try to keep the frequency updated as often as possible on a CPU.
This is a temporary/hack patch included for completeness and not intended for merging. Your machine may crash if the rdpmc instruction is unsupported!
There was this aperf/mperf approach on x86 which was already mainlined commit 47fe38fcff05 ("x86: sched: Provide arch implementations using aperf/mperf"). It has been removed since then by commit 61c63e5ed3b9 ("cpufreq: Remove unused APERF/MPERF support") and commit ee08d1284ea9 ("sched/x86: Remove broken power estimation") but people mentioned this in the meantime when it came to frequency invariance on x86.
Any particular reason why you prefer 'rdpmc' instead?
rdmpc to me seemed to be a more recent addition and the simplest and fastest way to get raw cpu cycles with a single register read. I wanted to trace the actual cycle count too in order to compare it with what software has voted and C-states etc. The aperf/mperf ratio derived from the MSRs seems less direct in that respect (not sure how turbo-boost would affect the max ratio value for instance).
I do need to reduce the overhead associated with this patch, perhaps by reading the counter during tick and context switches and a very few more places.
Thanks, Vikram