2017-06-24 13:11:52 +08:00
|
|
|
/*
|
|
|
|
* x86 APERF/MPERF KHz calculation for
|
|
|
|
* /sys/.../cpufreq/scaling_cur_freq
|
|
|
|
*
|
|
|
|
* Copyright (C) 2017 Intel Corp.
|
|
|
|
* Author: Len Brown <len.brown@intel.com>
|
|
|
|
*
|
|
|
|
* This file is licensed under GPLv2.
|
|
|
|
*/
|
|
|
|
|
2017-07-28 20:45:03 +08:00
|
|
|
#include <linux/delay.h>
|
|
|
|
#include <linux/ktime.h>
|
2017-06-24 13:11:52 +08:00
|
|
|
#include <linux/math64.h>
|
|
|
|
#include <linux/percpu.h>
|
2018-12-05 07:34:56 +08:00
|
|
|
#include <linux/cpufreq.h>
|
2017-06-24 13:11:52 +08:00
|
|
|
#include <linux/smp.h>
|
|
|
|
|
x86 / CPU: Always show current CPU frequency in /proc/cpuinfo
After commit 890da9cf0983 (Revert "x86: do not use cpufreq_quick_get()
for /proc/cpuinfo "cpu MHz"") the "cpu MHz" number in /proc/cpuinfo
on x86 can be either the nominal CPU frequency (which is constant)
or the frequency most recently requested by a scaling governor in
cpufreq, depending on the cpufreq configuration. That is somewhat
inconsistent and is different from what it was before 4.13, so in
order to restore the previous behavior, make it report the current
CPU frequency like the scaling_cur_freq sysfs file in cpufreq.
To that end, modify the /proc/cpuinfo implementation on x86 to use
aperfmperf_snapshot_khz() to snapshot the APERF and MPERF feedback
registers, if available, and use their values to compute the CPU
frequency to be reported as "cpu MHz".
However, do that carefully enough to avoid accumulating delays that
lead to unacceptable access times for /proc/cpuinfo on systems with
many CPUs. Run aperfmperf_snapshot_khz() once on all CPUs
asynchronously at the /proc/cpuinfo open time, add a single delay
upfront (if necessary) at that point and simply compute the current
frequency while running show_cpuinfo() for each individual CPU.
Also, to avoid slowing down /proc/cpuinfo accesses too much, reduce
the default delay between consecutive APERF and MPERF reads to 10 ms,
which should be sufficient to get large enough numbers for the
frequency computation in all cases.
Fixes: 890da9cf0983 (Revert "x86: do not use cpufreq_quick_get() for /proc/cpuinfo "cpu MHz"")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ingo Molnar <mingo@kernel.org>
2017-11-15 09:13:40 +08:00
|
|
|
#include "cpu.h"
|
|
|
|
|
2017-06-24 13:11:52 +08:00
|
|
|
struct aperfmperf_sample {
|
|
|
|
unsigned int khz;
|
2017-07-28 20:45:03 +08:00
|
|
|
ktime_t time;
|
2017-06-24 13:11:52 +08:00
|
|
|
u64 aperf;
|
|
|
|
u64 mperf;
|
|
|
|
};
|
|
|
|
|
|
|
|
static DEFINE_PER_CPU(struct aperfmperf_sample, samples);
|
|
|
|
|
2017-07-28 20:45:03 +08:00
|
|
|
#define APERFMPERF_CACHE_THRESHOLD_MS 10
|
x86 / CPU: Always show current CPU frequency in /proc/cpuinfo
After commit 890da9cf0983 (Revert "x86: do not use cpufreq_quick_get()
for /proc/cpuinfo "cpu MHz"") the "cpu MHz" number in /proc/cpuinfo
on x86 can be either the nominal CPU frequency (which is constant)
or the frequency most recently requested by a scaling governor in
cpufreq, depending on the cpufreq configuration. That is somewhat
inconsistent and is different from what it was before 4.13, so in
order to restore the previous behavior, make it report the current
CPU frequency like the scaling_cur_freq sysfs file in cpufreq.
To that end, modify the /proc/cpuinfo implementation on x86 to use
aperfmperf_snapshot_khz() to snapshot the APERF and MPERF feedback
registers, if available, and use their values to compute the CPU
frequency to be reported as "cpu MHz".
However, do that carefully enough to avoid accumulating delays that
lead to unacceptable access times for /proc/cpuinfo on systems with
many CPUs. Run aperfmperf_snapshot_khz() once on all CPUs
asynchronously at the /proc/cpuinfo open time, add a single delay
upfront (if necessary) at that point and simply compute the current
frequency while running show_cpuinfo() for each individual CPU.
Also, to avoid slowing down /proc/cpuinfo accesses too much, reduce
the default delay between consecutive APERF and MPERF reads to 10 ms,
which should be sufficient to get large enough numbers for the
frequency computation in all cases.
Fixes: 890da9cf0983 (Revert "x86: do not use cpufreq_quick_get() for /proc/cpuinfo "cpu MHz"")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ingo Molnar <mingo@kernel.org>
2017-11-15 09:13:40 +08:00
|
|
|
#define APERFMPERF_REFRESH_DELAY_MS 10
|
2017-07-28 20:45:03 +08:00
|
|
|
#define APERFMPERF_STALE_THRESHOLD_MS 1000
|
|
|
|
|
2017-06-24 13:11:52 +08:00
|
|
|
/*
|
|
|
|
* aperfmperf_snapshot_khz()
|
|
|
|
* On the current CPU, snapshot APERF, MPERF, and jiffies
|
|
|
|
* unless we already did it within 10ms
|
|
|
|
* calculate kHz, save snapshot
|
|
|
|
*/
|
|
|
|
static void aperfmperf_snapshot_khz(void *dummy)
|
|
|
|
{
|
|
|
|
u64 aperf, aperf_delta;
|
|
|
|
u64 mperf, mperf_delta;
|
|
|
|
struct aperfmperf_sample *s = this_cpu_ptr(&samples);
|
2017-08-09 05:12:49 +08:00
|
|
|
unsigned long flags;
|
2017-06-24 13:11:52 +08:00
|
|
|
|
2017-08-09 05:12:49 +08:00
|
|
|
local_irq_save(flags);
|
2017-06-24 13:11:52 +08:00
|
|
|
rdmsrl(MSR_IA32_APERF, aperf);
|
|
|
|
rdmsrl(MSR_IA32_MPERF, mperf);
|
2017-08-09 05:12:49 +08:00
|
|
|
local_irq_restore(flags);
|
2017-06-24 13:11:52 +08:00
|
|
|
|
|
|
|
aperf_delta = aperf - s->aperf;
|
|
|
|
mperf_delta = mperf - s->mperf;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* There is no architectural guarantee that MPERF
|
|
|
|
* increments faster than we can read it.
|
|
|
|
*/
|
|
|
|
if (mperf_delta == 0)
|
|
|
|
return;
|
|
|
|
|
x86 / CPU: Always show current CPU frequency in /proc/cpuinfo
After commit 890da9cf0983 (Revert "x86: do not use cpufreq_quick_get()
for /proc/cpuinfo "cpu MHz"") the "cpu MHz" number in /proc/cpuinfo
on x86 can be either the nominal CPU frequency (which is constant)
or the frequency most recently requested by a scaling governor in
cpufreq, depending on the cpufreq configuration. That is somewhat
inconsistent and is different from what it was before 4.13, so in
order to restore the previous behavior, make it report the current
CPU frequency like the scaling_cur_freq sysfs file in cpufreq.
To that end, modify the /proc/cpuinfo implementation on x86 to use
aperfmperf_snapshot_khz() to snapshot the APERF and MPERF feedback
registers, if available, and use their values to compute the CPU
frequency to be reported as "cpu MHz".
However, do that carefully enough to avoid accumulating delays that
lead to unacceptable access times for /proc/cpuinfo on systems with
many CPUs. Run aperfmperf_snapshot_khz() once on all CPUs
asynchronously at the /proc/cpuinfo open time, add a single delay
upfront (if necessary) at that point and simply compute the current
frequency while running show_cpuinfo() for each individual CPU.
Also, to avoid slowing down /proc/cpuinfo accesses too much, reduce
the default delay between consecutive APERF and MPERF reads to 10 ms,
which should be sufficient to get large enough numbers for the
frequency computation in all cases.
Fixes: 890da9cf0983 (Revert "x86: do not use cpufreq_quick_get() for /proc/cpuinfo "cpu MHz"")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ingo Molnar <mingo@kernel.org>
2017-11-15 09:13:40 +08:00
|
|
|
s->time = ktime_get();
|
2017-06-24 13:11:52 +08:00
|
|
|
s->aperf = aperf;
|
|
|
|
s->mperf = mperf;
|
x86 / CPU: Always show current CPU frequency in /proc/cpuinfo
After commit 890da9cf0983 (Revert "x86: do not use cpufreq_quick_get()
for /proc/cpuinfo "cpu MHz"") the "cpu MHz" number in /proc/cpuinfo
on x86 can be either the nominal CPU frequency (which is constant)
or the frequency most recently requested by a scaling governor in
cpufreq, depending on the cpufreq configuration. That is somewhat
inconsistent and is different from what it was before 4.13, so in
order to restore the previous behavior, make it report the current
CPU frequency like the scaling_cur_freq sysfs file in cpufreq.
To that end, modify the /proc/cpuinfo implementation on x86 to use
aperfmperf_snapshot_khz() to snapshot the APERF and MPERF feedback
registers, if available, and use their values to compute the CPU
frequency to be reported as "cpu MHz".
However, do that carefully enough to avoid accumulating delays that
lead to unacceptable access times for /proc/cpuinfo on systems with
many CPUs. Run aperfmperf_snapshot_khz() once on all CPUs
asynchronously at the /proc/cpuinfo open time, add a single delay
upfront (if necessary) at that point and simply compute the current
frequency while running show_cpuinfo() for each individual CPU.
Also, to avoid slowing down /proc/cpuinfo accesses too much, reduce
the default delay between consecutive APERF and MPERF reads to 10 ms,
which should be sufficient to get large enough numbers for the
frequency computation in all cases.
Fixes: 890da9cf0983 (Revert "x86: do not use cpufreq_quick_get() for /proc/cpuinfo "cpu MHz"")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ingo Molnar <mingo@kernel.org>
2017-11-15 09:13:40 +08:00
|
|
|
s->khz = div64_u64((cpu_khz * aperf_delta), mperf_delta);
|
2017-06-24 13:11:52 +08:00
|
|
|
}
|
|
|
|
|
x86 / CPU: Always show current CPU frequency in /proc/cpuinfo
After commit 890da9cf0983 (Revert "x86: do not use cpufreq_quick_get()
for /proc/cpuinfo "cpu MHz"") the "cpu MHz" number in /proc/cpuinfo
on x86 can be either the nominal CPU frequency (which is constant)
or the frequency most recently requested by a scaling governor in
cpufreq, depending on the cpufreq configuration. That is somewhat
inconsistent and is different from what it was before 4.13, so in
order to restore the previous behavior, make it report the current
CPU frequency like the scaling_cur_freq sysfs file in cpufreq.
To that end, modify the /proc/cpuinfo implementation on x86 to use
aperfmperf_snapshot_khz() to snapshot the APERF and MPERF feedback
registers, if available, and use their values to compute the CPU
frequency to be reported as "cpu MHz".
However, do that carefully enough to avoid accumulating delays that
lead to unacceptable access times for /proc/cpuinfo on systems with
many CPUs. Run aperfmperf_snapshot_khz() once on all CPUs
asynchronously at the /proc/cpuinfo open time, add a single delay
upfront (if necessary) at that point and simply compute the current
frequency while running show_cpuinfo() for each individual CPU.
Also, to avoid slowing down /proc/cpuinfo accesses too much, reduce
the default delay between consecutive APERF and MPERF reads to 10 ms,
which should be sufficient to get large enough numbers for the
frequency computation in all cases.
Fixes: 890da9cf0983 (Revert "x86: do not use cpufreq_quick_get() for /proc/cpuinfo "cpu MHz"")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ingo Molnar <mingo@kernel.org>
2017-11-15 09:13:40 +08:00
|
|
|
static bool aperfmperf_snapshot_cpu(int cpu, ktime_t now, bool wait)
|
2017-06-24 13:11:52 +08:00
|
|
|
{
|
x86 / CPU: Always show current CPU frequency in /proc/cpuinfo
After commit 890da9cf0983 (Revert "x86: do not use cpufreq_quick_get()
for /proc/cpuinfo "cpu MHz"") the "cpu MHz" number in /proc/cpuinfo
on x86 can be either the nominal CPU frequency (which is constant)
or the frequency most recently requested by a scaling governor in
cpufreq, depending on the cpufreq configuration. That is somewhat
inconsistent and is different from what it was before 4.13, so in
order to restore the previous behavior, make it report the current
CPU frequency like the scaling_cur_freq sysfs file in cpufreq.
To that end, modify the /proc/cpuinfo implementation on x86 to use
aperfmperf_snapshot_khz() to snapshot the APERF and MPERF feedback
registers, if available, and use their values to compute the CPU
frequency to be reported as "cpu MHz".
However, do that carefully enough to avoid accumulating delays that
lead to unacceptable access times for /proc/cpuinfo on systems with
many CPUs. Run aperfmperf_snapshot_khz() once on all CPUs
asynchronously at the /proc/cpuinfo open time, add a single delay
upfront (if necessary) at that point and simply compute the current
frequency while running show_cpuinfo() for each individual CPU.
Also, to avoid slowing down /proc/cpuinfo accesses too much, reduce
the default delay between consecutive APERF and MPERF reads to 10 ms,
which should be sufficient to get large enough numbers for the
frequency computation in all cases.
Fixes: 890da9cf0983 (Revert "x86: do not use cpufreq_quick_get() for /proc/cpuinfo "cpu MHz"")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ingo Molnar <mingo@kernel.org>
2017-11-15 09:13:40 +08:00
|
|
|
s64 time_delta = ktime_ms_delta(now, per_cpu(samples.time, cpu));
|
|
|
|
|
|
|
|
/* Don't bother re-computing within the cache threshold time. */
|
|
|
|
if (time_delta < APERFMPERF_CACHE_THRESHOLD_MS)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
smp_call_function_single(cpu, aperfmperf_snapshot_khz, NULL, wait);
|
|
|
|
|
|
|
|
/* Return false if the previous iteration was too long ago. */
|
|
|
|
return time_delta <= APERFMPERF_STALE_THRESHOLD_MS;
|
|
|
|
}
|
2017-07-28 20:45:03 +08:00
|
|
|
|
x86 / CPU: Always show current CPU frequency in /proc/cpuinfo
After commit 890da9cf0983 (Revert "x86: do not use cpufreq_quick_get()
for /proc/cpuinfo "cpu MHz"") the "cpu MHz" number in /proc/cpuinfo
on x86 can be either the nominal CPU frequency (which is constant)
or the frequency most recently requested by a scaling governor in
cpufreq, depending on the cpufreq configuration. That is somewhat
inconsistent and is different from what it was before 4.13, so in
order to restore the previous behavior, make it report the current
CPU frequency like the scaling_cur_freq sysfs file in cpufreq.
To that end, modify the /proc/cpuinfo implementation on x86 to use
aperfmperf_snapshot_khz() to snapshot the APERF and MPERF feedback
registers, if available, and use their values to compute the CPU
frequency to be reported as "cpu MHz".
However, do that carefully enough to avoid accumulating delays that
lead to unacceptable access times for /proc/cpuinfo on systems with
many CPUs. Run aperfmperf_snapshot_khz() once on all CPUs
asynchronously at the /proc/cpuinfo open time, add a single delay
upfront (if necessary) at that point and simply compute the current
frequency while running show_cpuinfo() for each individual CPU.
Also, to avoid slowing down /proc/cpuinfo accesses too much, reduce
the default delay between consecutive APERF and MPERF reads to 10 ms,
which should be sufficient to get large enough numbers for the
frequency computation in all cases.
Fixes: 890da9cf0983 (Revert "x86: do not use cpufreq_quick_get() for /proc/cpuinfo "cpu MHz"")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ingo Molnar <mingo@kernel.org>
2017-11-15 09:13:40 +08:00
|
|
|
unsigned int aperfmperf_get_khz(int cpu)
|
|
|
|
{
|
2017-06-24 13:11:52 +08:00
|
|
|
if (!cpu_khz)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (!static_cpu_has(X86_FEATURE_APERFMPERF))
|
|
|
|
return 0;
|
|
|
|
|
x86 / CPU: Always show current CPU frequency in /proc/cpuinfo
After commit 890da9cf0983 (Revert "x86: do not use cpufreq_quick_get()
for /proc/cpuinfo "cpu MHz"") the "cpu MHz" number in /proc/cpuinfo
on x86 can be either the nominal CPU frequency (which is constant)
or the frequency most recently requested by a scaling governor in
cpufreq, depending on the cpufreq configuration. That is somewhat
inconsistent and is different from what it was before 4.13, so in
order to restore the previous behavior, make it report the current
CPU frequency like the scaling_cur_freq sysfs file in cpufreq.
To that end, modify the /proc/cpuinfo implementation on x86 to use
aperfmperf_snapshot_khz() to snapshot the APERF and MPERF feedback
registers, if available, and use their values to compute the CPU
frequency to be reported as "cpu MHz".
However, do that carefully enough to avoid accumulating delays that
lead to unacceptable access times for /proc/cpuinfo on systems with
many CPUs. Run aperfmperf_snapshot_khz() once on all CPUs
asynchronously at the /proc/cpuinfo open time, add a single delay
upfront (if necessary) at that point and simply compute the current
frequency while running show_cpuinfo() for each individual CPU.
Also, to avoid slowing down /proc/cpuinfo accesses too much, reduce
the default delay between consecutive APERF and MPERF reads to 10 ms,
which should be sufficient to get large enough numbers for the
frequency computation in all cases.
Fixes: 890da9cf0983 (Revert "x86: do not use cpufreq_quick_get() for /proc/cpuinfo "cpu MHz"")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ingo Molnar <mingo@kernel.org>
2017-11-15 09:13:40 +08:00
|
|
|
aperfmperf_snapshot_cpu(cpu, ktime_get(), true);
|
|
|
|
return per_cpu(samples.khz, cpu);
|
|
|
|
}
|
2017-11-13 09:15:39 +08:00
|
|
|
|
x86 / CPU: Always show current CPU frequency in /proc/cpuinfo
After commit 890da9cf0983 (Revert "x86: do not use cpufreq_quick_get()
for /proc/cpuinfo "cpu MHz"") the "cpu MHz" number in /proc/cpuinfo
on x86 can be either the nominal CPU frequency (which is constant)
or the frequency most recently requested by a scaling governor in
cpufreq, depending on the cpufreq configuration. That is somewhat
inconsistent and is different from what it was before 4.13, so in
order to restore the previous behavior, make it report the current
CPU frequency like the scaling_cur_freq sysfs file in cpufreq.
To that end, modify the /proc/cpuinfo implementation on x86 to use
aperfmperf_snapshot_khz() to snapshot the APERF and MPERF feedback
registers, if available, and use their values to compute the CPU
frequency to be reported as "cpu MHz".
However, do that carefully enough to avoid accumulating delays that
lead to unacceptable access times for /proc/cpuinfo on systems with
many CPUs. Run aperfmperf_snapshot_khz() once on all CPUs
asynchronously at the /proc/cpuinfo open time, add a single delay
upfront (if necessary) at that point and simply compute the current
frequency while running show_cpuinfo() for each individual CPU.
Also, to avoid slowing down /proc/cpuinfo accesses too much, reduce
the default delay between consecutive APERF and MPERF reads to 10 ms,
which should be sufficient to get large enough numbers for the
frequency computation in all cases.
Fixes: 890da9cf0983 (Revert "x86: do not use cpufreq_quick_get() for /proc/cpuinfo "cpu MHz"")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ingo Molnar <mingo@kernel.org>
2017-11-15 09:13:40 +08:00
|
|
|
void arch_freq_prepare_all(void)
|
|
|
|
{
|
|
|
|
ktime_t now = ktime_get();
|
|
|
|
bool wait = false;
|
|
|
|
int cpu;
|
|
|
|
|
|
|
|
if (!cpu_khz)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (!static_cpu_has(X86_FEATURE_APERFMPERF))
|
|
|
|
return;
|
|
|
|
|
|
|
|
for_each_online_cpu(cpu)
|
|
|
|
if (!aperfmperf_snapshot_cpu(cpu, now, false))
|
|
|
|
wait = true;
|
|
|
|
|
|
|
|
if (wait)
|
|
|
|
msleep(APERFMPERF_REFRESH_DELAY_MS);
|
|
|
|
}
|
|
|
|
|
|
|
|
unsigned int arch_freq_get_on_cpu(int cpu)
|
|
|
|
{
|
|
|
|
if (!cpu_khz)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (!static_cpu_has(X86_FEATURE_APERFMPERF))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (aperfmperf_snapshot_cpu(cpu, ktime_get(), true))
|
|
|
|
return per_cpu(samples.khz, cpu);
|
2017-07-28 20:45:03 +08:00
|
|
|
|
|
|
|
msleep(APERFMPERF_REFRESH_DELAY_MS);
|
|
|
|
smp_call_function_single(cpu, aperfmperf_snapshot_khz, NULL, 1);
|
2017-06-24 13:11:52 +08:00
|
|
|
|
|
|
|
return per_cpu(samples.khz, cpu);
|
|
|
|
}
|