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?
[...]