From: "Doug Smythies" <dsmythies@telus.net>
To: "'Rafael J. Wysocki'" <rjw@rjwysocki.net>,
x86@kernel.org, linux-pm@vger.kernel.org
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>
Subject: RE: [PATCH v2] cpufreq: x86: Make scaling_cur_freq behave more as expected
Date: Mon, 31 Jul 2017 16:46:42 -0700 [thread overview]
Message-ID: <002201d30a57$44f2ed40$ced8c7c0$@net> (raw)
In-Reply-To: b4lNdC8DshlzSb4lSd2K7O
On 2017.07.28 05:45 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 iteration
> of aperfmperf_snapshot_khz() which may be stale.
>
> To prevent that from happening, 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).
...[deleted the rest]...
This patch seems to work fine and addresses my complaints from last week.
Thanks.
... Doug
WARNING: multiple messages have this Message-ID (diff)
From: "Doug Smythies" <dsmythies@telus.net>
To: "'Rafael J. Wysocki'" <rjw@rjwysocki.net>, <x86@kernel.org>,
<linux-pm@vger.kernel.org>
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>
Subject: RE: [PATCH v2] cpufreq: x86: Make scaling_cur_freq behave more as expected
Date: Mon, 31 Jul 2017 16:46:42 -0700 [thread overview]
Message-ID: <002201d30a57$44f2ed40$ced8c7c0$@net> (raw)
In-Reply-To: b4lNdC8DshlzSb4lSd2K7O
On 2017.07.28 05:45 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 iteration
> of aperfmperf_snapshot_khz() which may be stale.
>
> To prevent that from happening, 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).
...[deleted the rest]...
This patch seems to work fine and addresses my complaints from last week.
Thanks.
... Doug
next prev parent reply other threads:[~2017-07-31 23:46 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 [this message]
2017-07-31 23:46 ` Doug Smythies
2017-08-01 0:50 ` Rafael J. Wysocki
2017-07-28 6:01 ` [PATCH] " Doug Smythies
2017-07-28 6:01 ` 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='002201d30a57$44f2ed40$ced8c7c0$@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.