lkml.org 
[lkml]   [2020]   [Jul]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 0/4] CPUFreq statistics retrieved by drivers
    On Thu, Jul 30, 2020 at 02:23:33PM +0530, Viresh Kumar wrote:
    > On 29-07-20, 16:12, Lukasz Luba wrote:
    > > The existing CPUFreq framework does not tracks the statistics when the
    > > 'fast switch' is used or when firmware changes the frequency independently
    > > due to e.g. thermal reasons. However, the firmware might track the frequency
    > > changes and expose this to the kernel.
    > >
    > > This patch set aims to introduce CPUfreq statistics gathered by firmware
    > > and retrieved by CPUFreq driver. It would require a new API functions
    > > in the CPUFreq, which allows to poke drivers to get these stats.
    > >
    > > The needed CPUFreq infrastructure is in patch 1/4, patch 2/4 extends
    > > ARM SCMI protocol layer, patches 3/4, 4/4 modify ARM SCMI CPUFreq driver.
    >
    > Are you doing this for the fast switch case or because your platform
    > actually runs at frequencies which may be different from what cpufreq
    > core has requested ?
    >

    I think so.

    > I am also not sure what these tables should represent, what the
    > cpufreq core has decided for the CPUs or the frequencies we actually
    > run at, as these two can be very different for example if the hardware
    > runs at frequencies which don't match exactly to what is there in the
    > freq table. I believe these are rather to show what cpufreq and its
    > governors are doing with the CPUs.
    >

    Exactly, I raised similar point in internal discussion and asked Lukasz
    to take up the same on the list. I assume it was always what cpufreq
    requested rather than what was delivered. So will we break the userspace
    ABI if we change that is the main question.

    > Over that I would like the userspace stats to work exactly as the way
    > they work right now, i.e. capture all transitions from one freq to
    > other, not just time-in-state. Also resetting of the stats from
    > userspace for example. All allocation and printing of the data must be
    > done from stats core, the only thing which the driver would do at the
    > end is updating the stats structure and nothing more. Instead of
    > reading all stats from the firmware, it will be much easier if you can
    > just get the information from the firmware whenever there is a
    > frequency switch and then we can update the stats the way it is done
    > right now. And that would be simple.
    >

    Good point, but notifications may not be lightweight. If that is no good,
    alternatively, I suggested to keep these firmware stats in a separate
    debugfs. Thoughts ?

    --
    Regards,
    Sudeep

    \
     
     \ /
      Last update: 2020-07-30 11:11    [W:3.009 / U:0.164 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site