From: Leonard Crestez <leonard.crestez@nxp.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>,
Viresh Kumar <viresh.kumar@linaro.org>
Cc: Shuah Khan <shuah@kernel.org>,
linux-kselftest@vger.kernel.org,
Octavian Purdila <octavian.purdila@nxp.com>,
Linux PM <linux-pm@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] selftests: cpufreq: Check cpuinfo_cur_freq set as expected
Date: Wed, 12 Jul 2017 19:51:27 +0300 [thread overview]
Message-ID: <1499878287.11612.35.camel@nxp.com> (raw)
In-Reply-To: <CAJZ5v0g5Chq-zw0tN6Mvp2YD2WKavUMp37UtAoFPLW3yiX4F1w@mail.gmail.com>
On Wed, 2017-07-12 at 13:36 +0200, Rafael J. Wysocki wrote:
> On Wed, Jul 12, 2017 at 1:29 PM, Leonard Crestez
> <leonard.crestez@nxp.com> wrote:
> >
> > This checks that the cpufreq driver actually sets the requested
> > frequency.
> This won't work on modern x86 with APERF/MPERF (see recent commits in
> that area).
This test should be skipped if the cpu always adjusts it's own
frequency dynamically. It should check if scaling_set_speed won't
reflect in cpuinfo_cur_freq, but I'm not sure how to do that reliably.
I checked with the intel_pstate driver and it's already skipped in this
test because no userspace governor is available. This could be a way to
check if the CPU supports targetting a precise constant frequency.
Or are you saying that cpuinfo_cur_freq in general shouldn't be
expected to just return the current frequency but also adjust for time
spent in various idle states? It seems to me that if you want to track
the current load it might be better to report this through different
more explicit mechanism.
In particular imx already supports cpuidle states where the arm core
clock is turned off and later resumed but this has no effect on
cpuinfo_cur_freq.
--
Regards,
Leonard
next prev parent reply other threads:[~2017-07-12 16:51 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-12 11:29 [PATCH] selftests: cpufreq: Check cpuinfo_cur_freq set as expected Leonard Crestez
2017-07-12 11:36 ` Rafael J. Wysocki
2017-07-12 16:51 ` Leonard Crestez [this message]
2017-07-12 20:38 ` Rafael J. Wysocki
2017-07-13 8:55 ` Viresh Kumar
2017-07-18 19:34 ` Leonard Crestez
2017-07-19 6:54 ` Viresh Kumar
2017-07-19 12:47 ` 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=1499878287.11612.35.camel@nxp.com \
--to=leonard.crestez@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=octavian.purdila@nxp.com \
--cc=rafael@kernel.org \
--cc=shuah@kernel.org \
--cc=viresh.kumar@linaro.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;
as well as URLs for NNTP newsgroup(s).