lkml.org 
[lkml]   [2014]   [Sep]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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)?


    \
     
     \ /
      Last update: 2014-09-10 02:01    [W:2.874 / U:2.260 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site