From: Prarit Bhargava <prarit@redhat.com>
To: linux-kernel@vger.kernel.org
Cc: lenb@kernel.org, Prarit Bhargava <prarit@redhat.com>
Subject: Re: [PATCH v2] x86: Calculate MHz using APERF/MPERF for cpuinfo and scaling_cur_freq
Date: Fri, 8 Apr 2016 08:26:07 -0400 [thread overview]
Message-ID: <1460118367-17489-1-git-send-email-prarit@redhat.com> (raw)
In-Reply-To: <2433e0a2ace56242bd67fd4ea13448125b1ed824.1459975343.git.len.brown@intel.com>
>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@intel.com>
next prev parent reply other threads:[~2016-04-08 12:26 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <6e0c25e64e0fb65a42dfc63ad5f660302e07cd87.1459975343.git.len.brown@intel.com>
2016-04-06 20:47 ` Len Brown
2016-04-08 12:26 ` Prarit Bhargava [this message]
2016-04-08 23:56 ` Len Brown
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=1460118367-17489-1-git-send-email-prarit@redhat.com \
--to=prarit@redhat.com \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®