Messages in this thread | | | Date | Tue, 9 Sep 2014 16:22:29 -0700 | From | Anup Chenthamarakshan <> | Subject | Re: [PATCH] intel_pstate: track and export frequency residency stats via sysfs. |
| |
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)?
| |