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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.