From: Anup Chenthamarakshan <anupc@chromium.org>
To: Dirk Brandewie <dirk.brandewie@gmail.com>
Cc: Dirk Brandewie <dirk.j.brandewie@intel.com>,
Sameer Nanda <snanda@chromium.org>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Viresh Kumar <viresh.kumar@linaro.org>,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] intel_pstate: track and export frequency residency stats via sysfs.
Date: Tue, 9 Sep 2014 16:22:29 -0700 [thread overview]
Message-ID: <20140909232229.GA28142@google.com> (raw)
In-Reply-To: <540F1981.1090805@gmail.com>
On Tue, Sep 09, 2014 at 08:15:13AM -0700, Dirk Brandewie wrote:
> On 09/08/2014 05:10 PM, Anup Chenthamarakshan wrote:
> > Exported stats appear in
> > <sysfs>/devices/system/cpu/intel_pstate/time_in_state as follows:
> >
> > ## CPU 0
> > 400000 3647
> > 500000 24342
> > 600000 144150
> > 700000 202469
> > ## CPU 1
> > 400000 4813
> > 500000 22628
> > 600000 149564
> > 700000 211885
> > 800000 173890
> >
> > Signed-off-by: Anup Chenthamarakshan <anupc@chromium.org>
>
> What is this information being used for?
I'm using P-state residency information in power consumption tests to calculate
proportion of time spent in each P-state across all processors (one global set
of percentages, corresponding to each P-state). This is used to validate new
changes from the power perspective. Essentially, sanity checks to flag changes
with large difference in P-state residency.
So far, we've been using the data exported by acpi-cpufreq to track this.
>
> Tracking the current P state request for each core is only part of the
> story. The processor aggregates the requests from all cores and then decides
> what frequency the package will run at, this evaluation happens at ~1ms time
> frame. If a core is idle then it loses its vote for that package frequency will
> be and its frequency will be zero even though it may have been requesting
> a high P state when it went idle. Tracking the residency of the requested
> P state doesn't provide much useful information other than ensuring the the
> requests are changing over time IMHO.
This is exactly why we're trying to track it.
>
> This interface will not be supportable with upcoming processors using
> hardware P states as documented in volume 3 of the current SDM Section 14.4
> http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf
> The OS will have no way of knowing what the P state requests are for a
> given core are.
Will there be any means to determine the proportion of time spent in different
HWP-states when HWP gets enabled (maybe at a package level)?
next prev parent reply other threads:[~2014-09-09 23:22 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-09 0:10 [PATCH] intel_pstate: track and export frequency residency stats via sysfs Anup Chenthamarakshan
2014-09-09 5:03 ` Viresh Kumar
2014-09-09 5:32 ` Anup Chenthamarakshan
2014-09-09 6:26 ` Viresh Kumar
2014-09-09 23:31 ` Anup Chenthamarakshan
2014-09-10 6:49 ` Viresh Kumar
2014-09-09 15:15 ` Dirk Brandewie
2014-09-09 23:22 ` Anup Chenthamarakshan [this message]
2014-09-10 16:39 ` Dirk Brandewie
2014-09-10 22:15 ` Anup Chenthamarakshan
2014-09-10 22:49 ` Rafael J. Wysocki
2014-09-10 23:39 ` Anup Chenthamarakshan
2014-09-11 0:04 ` Rafael J. Wysocki
2014-09-11 1:04 ` Sameer Nanda
2014-09-11 15:37 ` Dirk Brandewie
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=20140909232229.GA28142@google.com \
--to=anupc@chromium.org \
--cc=dirk.brandewie@gmail.com \
--cc=dirk.j.brandewie@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rjw@rjwysocki.net \
--cc=snanda@chromium.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).