linux-kernel - Re: [PATCH v2] x86: Calculate MHz using APERF/MPERF for cpuinfo and scaling_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]

Message-Id: <1460118367-17489-1-git-send-email-prarit@redhat.com>
Date:	Fri,  8 Apr 2016 08:26:07 -0400
From:	Prarit Bhargava <prarit@...hat.com>
To:	linux-kernel@...r.kernel.org
Cc:	lenb@...nel.org, Prarit Bhargava <prarit@...hat.com>
Subject: Re: [PATCH v2] x86: Calculate MHz using APERF/MPERF for cpuinfo and scaling_cur_freq

>For x86 processors with APERF/MPERF and TSC, return
> meaningful and consistent MHz in /proc/cpuinfo and
> /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq
>
>MHz is computed like so:
>
>MHz = base_MHz * delta_APERF / delta_MPERF
>
>or when delta_APERF is large, to prevent
>64-bit overflow:
>
>MHz = delta_APERF / (delta_MPERF / base_MHz)
>
>MHz is the average frequency of the busy processor
>over a measurement interval.  The interval is
>defined to be the time between successive reads
>of the frequency on that processor, whether from
>/proc/cpuinfo or from sysfs cpufreq/scaling_cur_freq.
>As with previous methods of calculating MHz,
>idle time is excluded.
>
>base_MHz above is from TSC calibration global "cpu_khz".
>
>This x86 native method to calculate MHz returns a meaningful result
>no matter if P-states are controlled by hardware or firmware
>and/or the Linux cpufreq sub-system is/is-not installed.
>
>Note that frequent or concurrent reads of /proc/cpuinfo
>or sysfs cpufreq/scaling_cur_freq will shorten the
>measurement interval seen by each reader.  The code
>mitigates that issue by caching results for 100ms.

I have a minor ABI concern with this patch.  It seems that there is much more
variance in the output of "cpu MHz" with this patch, and I think that
needs to be noted in the changelog.

ISTR having a conversation a while ago (with you Len?  with Srinivas?)
where I mentioned that "cpu MHz" used to just reflect the "marketing"
frequency of the processors on the system.  Is it worth going back to
that static state, and leaving the calculation for the current frequency to
userspace programs like turbostat, cpupower, etc.?

FWIW: I *regularly* get bugzillas filed from people who do not understand
that "cpu MHz" shows the current frequency of the core.  I've often
thought it would be easier to make that value static ...

P.

>
>Discerning users are encouraged to take advantage of
>the turbostat(8) utility, which can gracefully handle
>concurrent measurement intervals of arbitrary length.
>
>Signed-off-by: Len Brown <len.brown@...el.com>