From: Thomas Gleixner <tglx@linutronix.de>
To: Len Brown <lenb@kernel.org>
Cc: rafael@kernel.org, x86@kernel.org,
srinivas.pandruvada@linux.intel.com, peterz@infradead.org,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
Len Brown <len.brown@intel.com>
Subject: Re: [PATCH 2/4] x86: use common aperfmperf_khz_on_cpu() to calculate KHz using APERF/MPERF
Date: Tue, 20 Jun 2017 12:15:10 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.20.1706201207170.1869@nanos> (raw)
In-Reply-To: <aba8474c690306eb708d4737d0b63c5ca448d019.1497665794.git.len.brown@intel.com>
On Fri, 16 Jun 2017, Len Brown wrote:
> +#include <linux/jiffies.h>
> +#include <linux/math64.h>
> +#include <linux/percpu.h>
> +#include <linux/smp.h>
> +
> +struct aperfmperf_sample {
> + unsigned int khz;
> + unsigned long jiffies;
> + u64 aperf;
> + u64 mperf;
Nit. Please write these in tabular fashion:
unsigned int khz;
unsigned long jiffies;
u64 aperf;
u64 mperf;
> +};
> +
> +static DEFINE_PER_CPU(struct aperfmperf_sample, samples);
> +
> +/*
> + * 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 = &get_cpu_var(samples);
This is invoked via a smp function call, so you want
this_cpu_ptr(samples)
here.
> + /* Don't bother re-computing within 10 ms */
> + if (time_before(jiffies, s->jiffies + HZ/100))
> + goto out;
That way you can spare the gotos and simply return
> index a5ce0bbe..cfc6220 100644
> --- a/include/linux/cpufreq.h
> +++ b/include/linux/cpufreq.h
> @@ -883,6 +883,19 @@ static inline bool policy_has_boost_freq(struct cpufreq_policy *policy)
> }
> #endif
>
> +#ifdef CONFIG_X86
> +extern unsigned int aperfmperf_khz_on_cpu(unsigned int cpu);
> +static inline unsigned int arch_freq_get_on_cpu(int cpu)
Please don't add arch specific crap in general headers.
Also having cpu as int and unsigned int is not really consistent.
The simple way to avoid that is to have a weak function and have an arch
override for it. If that does not work because the cpufreq stuff must be
built as a module, then you still can avoid CONFIG_X86 and have something
like CONFIG_ARCH_HAS_FOO.
Thanks,
tglx
next prev parent reply other threads:[~2017-06-20 10:15 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-17 3:03 [GIT PULL] x86,cpufreq: unify APERF/MPERF computation Len Brown
2017-06-17 3:03 ` [PATCH 1/4] x86: do not use cpufreq_quick_get() for /proc/cpuinfo "cpu MHz" Len Brown
2017-06-17 3:03 ` [PATCH 2/4] x86: use common aperfmperf_khz_on_cpu() to calculate KHz using APERF/MPERF Len Brown
2017-06-20 10:15 ` Thomas Gleixner [this message]
2017-06-24 5:03 ` Len Brown
2017-06-17 3:03 ` [PATCH 3/4] intel_pstate: delete scheduler hook in HWP mode Len Brown
2017-06-17 3:03 ` [PATCH 4/4] intel_pstate: skip scheduler hook when in "performance" mode Len Brown
2017-06-20 10:15 ` [PATCH 1/4] x86: do not use cpufreq_quick_get() for /proc/cpuinfo "cpu MHz" Thomas Gleixner
2017-06-19 12:45 ` [GIT PULL] x86,cpufreq: unify APERF/MPERF computation Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.20.1706201207170.1869@nanos \
--to=tglx@linutronix.de \
--cc=len.brown@intel.com \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=rafael@kernel.org \
--cc=srinivas.pandruvada@linux.intel.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox