From: "Doug Smythies" <dsmythies@telus.net>
To: "'Rafael J. Wysocki'" <rjw@rjwysocki.net>
Cc: 'Len Brown' <lenb@kernel.org>,
rafael@kernel.org, tglx@linutronix.de,
srinivas.pandruvada@linux.intel.com, peterz@infradead.org,
linux-kernel@vger.kernel.org, 'Len Brown' <len.brown@intel.com>,
x86@kernel.org, linux-pm@vger.kernel.org
Subject: RE: [PATCH] cpufreq: x86: Make scaling_cur_freq behave more as expected
Date: Thu, 27 Jul 2017 23:01:39 -0700 [thread overview]
Message-ID: <001901d30766$fc66a3c0$f533eb40$@net> (raw)
In-Reply-To: at1wdL9D9BxRWat21ddU41
On 2017.07.27 17:13 Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>
> After commit f8475cef9008 "x86: use common aperfmperf_khz_on_cpu() to
> calculate KHz using APERF/MPERF" the scaling_cur_freq policy attribute
> in sysfs only behaves as expected on x86 with APERF/MPERF registers
> available when it is read from at least twice in a row.
>
> The value returned by the first read may not be meaningful, because
> the computations in there use cached values from the previous
> aperfmperf_snapshot_khz() call which may be stale. However, the
> interface is expected to return meaningful values on every read,
> including the first one.
>
> To address this problem modify arch_freq_get_on_cpu() to call
> aperfmperf_snapshot_khz() twice, with a short delay between
> these calls, if the previous invocation of aperfmperf_snapshot_khz()
> was too far back in the past (specifically, more that 1s ago) and
> adjust aperfmperf_snapshot_khz() for that.
>
> Fixes: f8475cef9008 "x86: use common aperfmperf_khz_on_cpu() to calculate KHz using APERF/MPERF"
> Reported-by: Doug Smythies <dsmythies@telus.net>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
> arch/x86/kernel/cpu/aperfmperf.c | 36 +++++++++++++++++++++++++++++-------
> 1 file changed, 29 insertions(+), 7 deletions(-)
>
> Index: linux-pm/arch/x86/kernel/cpu/aperfmperf.c
...[deleted the rest]...
This proposed patch would be good. However, I can only try it maybe by Sunday.
I think the maximum time span means that this code:
/*
* if (cpu_khz * aperf_delta) fits into ULLONG_MAX, then
* khz = (cpu_khz * aperf_delta) / mperf_delta
*/
if (div64_u64(ULLONG_MAX, cpu_khz) > aperf_delta)
s->khz = div64_u64((cpu_khz * aperf_delta), mperf_delta);
else /* khz = aperf_delta / (mperf_delta / cpu_khz) */
s->khz = div64_u64(aperf_delta,
div64_u64(mperf_delta, cpu_khz));
Could be reduced to this:
s->khz = div64_u64((cpu_khz * aperf_delta), mperf_delta);
Because it could never overflow anymore.
... Doug
WARNING: multiple messages have this Message-ID (diff)
From: "Doug Smythies" <dsmythies@telus.net>
To: "'Rafael J. Wysocki'" <rjw@rjwysocki.net>
Cc: "'Len Brown'" <lenb@kernel.org>, <rafael@kernel.org>,
<tglx@linutronix.de>, <srinivas.pandruvada@linux.intel.com>,
<peterz@infradead.org>, <linux-kernel@vger.kernel.org>,
"'Len Brown'" <len.brown@intel.com>, <x86@kernel.org>,
<linux-pm@vger.kernel.org>
Subject: RE: [PATCH] cpufreq: x86: Make scaling_cur_freq behave more as expected
Date: Thu, 27 Jul 2017 23:01:39 -0700 [thread overview]
Message-ID: <001901d30766$fc66a3c0$f533eb40$@net> (raw)
In-Reply-To: at1wdL9D9BxRWat21ddU41
On 2017.07.27 17:13 Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>
> After commit f8475cef9008 "x86: use common aperfmperf_khz_on_cpu() to
> calculate KHz using APERF/MPERF" the scaling_cur_freq policy attribute
> in sysfs only behaves as expected on x86 with APERF/MPERF registers
> available when it is read from at least twice in a row.
>
> The value returned by the first read may not be meaningful, because
> the computations in there use cached values from the previous
> aperfmperf_snapshot_khz() call which may be stale. However, the
> interface is expected to return meaningful values on every read,
> including the first one.
>
> To address this problem modify arch_freq_get_on_cpu() to call
> aperfmperf_snapshot_khz() twice, with a short delay between
> these calls, if the previous invocation of aperfmperf_snapshot_khz()
> was too far back in the past (specifically, more that 1s ago) and
> adjust aperfmperf_snapshot_khz() for that.
>
> Fixes: f8475cef9008 "x86: use common aperfmperf_khz_on_cpu() to calculate KHz using APERF/MPERF"
> Reported-by: Doug Smythies <dsmythies@telus.net>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
> arch/x86/kernel/cpu/aperfmperf.c | 36 +++++++++++++++++++++++++++++-------
> 1 file changed, 29 insertions(+), 7 deletions(-)
>
> Index: linux-pm/arch/x86/kernel/cpu/aperfmperf.c
...[deleted the rest]...
This proposed patch would be good. However, I can only try it maybe by Sunday.
I think the maximum time span means that this code:
/*
* if (cpu_khz * aperf_delta) fits into ULLONG_MAX, then
* khz = (cpu_khz * aperf_delta) / mperf_delta
*/
if (div64_u64(ULLONG_MAX, cpu_khz) > aperf_delta)
s->khz = div64_u64((cpu_khz * aperf_delta), mperf_delta);
else /* khz = aperf_delta / (mperf_delta / cpu_khz) */
s->khz = div64_u64(aperf_delta,
div64_u64(mperf_delta, cpu_khz));
Could be reduced to this:
s->khz = div64_u64((cpu_khz * aperf_delta), mperf_delta);
Because it could never overflow anymore.
... Doug
next prev parent reply other threads:[~2017-07-28 6:01 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-24 5:11 [PATCH 0/4 v2] x86,cpufreq: unify APERF/MPERF computation Len Brown
2017-06-24 5:11 ` [PATCH 1/4] x86: do not use cpufreq_quick_get() for /proc/cpuinfo "cpu MHz" Len Brown
2017-06-24 5:11 ` [PATCH 2/4 v2] x86: use common aperfmperf_khz_on_cpu() to calculate KHz using APERF/MPERF Len Brown
2017-06-24 8:56 ` Thomas Gleixner
2017-06-24 12:03 ` Rafael J. Wysocki
2017-06-24 5:11 ` [PATCH 3/4] intel_pstate: delete scheduler hook in HWP mode Len Brown
2017-06-24 5:11 ` [PATCH 4/4] intel_pstate: skip scheduler hook when in "performance" mode Len Brown
2017-07-25 22:32 ` [PATCH 2/4 v2] x86: use common aperfmperf_khz_on_cpu() to calculate KHz using APERF/MPERF Doug Smythies
2017-07-25 22:32 ` Doug Smythies
2017-07-26 17:23 ` Len Brown
2017-07-28 0:13 ` [PATCH] cpufreq: x86: Make scaling_cur_freq behave more as expected Rafael J. Wysocki
2017-07-28 12:45 ` [PATCH v2] " Rafael J. Wysocki
2017-07-31 23:46 ` Doug Smythies
2017-07-31 23:46 ` Doug Smythies
2017-08-01 0:50 ` Rafael J. Wysocki
2017-07-28 6:01 ` Doug Smythies [this message]
2017-07-28 6:01 ` [PATCH] " Doug Smythies
2017-07-28 12:26 ` 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='001901d30766$fc66a3c0$f533eb40$@net' \
--to=dsmythies@telus.net \
--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=rjw@rjwysocki.net \
--cc=srinivas.pandruvada@linux.intel.com \
--cc=tglx@linutronix.de \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.