linux-kernel - Re: [PATCH] selftests: cpufreq: Check cpuinfo_cur

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 12 Jul 2017 19:51:27 +0300
From:   Leonard Crestez <leonard.crestez@....com>
To:     "Rafael J. Wysocki" <rafael@...nel.org>,
        Viresh Kumar <viresh.kumar@...aro.org>
CC:     Shuah Khan <shuah@...nel.org>, <linux-kselftest@...r.kernel.org>,
        "Octavian Purdila" <octavian.purdila@....com>,
        Linux PM <linux-pm@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] selftests: cpufreq: Check cpuinfo_cur_freq set as
 expected

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@....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