[lkml]   [2010]   [Mar]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 5/5] cpufreq: Add support for actual freq
    On Tuesday 23 March 2010 15:23:49 Borislav Petkov wrote:
    > From: Thomas Renninger <>
    > Date: Tue, Mar 23, 2010 at 12:51:18PM +0100
    > Hi,
    > > scaling_cur freq should show the frequency the kernel/cpufreq
    > > subsystem thinks it's in.
    > Well, we have also
    > /sys/devices/system/cpu/cpu<NUM>/cpufreq/cpuinfo_cur_freq and it reads
    > also policy->cur. Why not show the actual frequency in scaling_cur_freq
    > then?
    > > You show the average freq and the time of the measured average
    > > frequency depends on when the cpufreq subsystem called getavg()
    > > the last time.
    > > Also the time frame of the average freq the cpufreq subsystem
    > > gets when calling getavg() now depends on whether and how often
    > > userspace calls scaling_cur_freq which influences switching policy.
    > >
    > > Latest cpufrequtils (ver 006) supports cpufreq-aperf to check whether
    > > cores enter boost mode. Len Brown afaik also has a userspace tool, but
    > > if it has any advantages, it should IMO get integrated into cpufrequtils
    > > which people know to use when looking at cpufreq.
    > >
    > > I once thought about adding scaling_avg_freq which gets an own
    > > aperf_mperf counter, but you don't know whether another app read out the
    > > average freq in between and your expected measured time frame is wrong then.
    > > You could remember aperf/mperf per pid and free the saved aperf/mperf value
    > > if the process dies..., but what for if this can be read out in userspace.
    > Ah yes, I see what you mean. Yet, I still don't like the idea of having
    > to use a special userspace tool just to read the actual frequency. How
    > about we hook into <drivers/cpufreq/cpufreq_ondemand.c:dbs_check_cpu()>
    > and passively output the freq_avg after being computed in
    > freq_avg = __cpufreq_driver_getavg(policy, j);
    > if (freq_avg <= 0)
    > freq_avg = policy->cur;
    > through sysfs. Hmm...?
    But what data would you get then? It's defintely not cur_freq.
    It's some kind of average, but you don't know the time frame.

    I posted a solution with an extra aperf/mperf save for scaling_avg_freq
    (or similar).
    First read would return nothing valid.
    cat scaling_avg_freq > /dev/null
    watch -n1 cat scaling_avg_freq
    would return the average freq of the last seconds, exactly the same
    what you can do with cpufreq-aperf from userspace.
    But if another user app does the same, it's messed up.
    You can find out the pid of the process doing the cat and remember
    aperf/mperf for it if it does not exist yet..., but now it gets to a
    point where cpufreq-aperf is really more convenient and straight foward.

    Possibly documenting cpufreq-aperf in Documentation/cpu-freq would
    be worth it. Also mentioning "boost" somewhere would be great:
    grep -i boost Documentation/cpu-freq/ -r
    Documentation/cpu-freq/pcc-cpufreq.txt:This is due to "turbo boost" ...

    Another idea is to have a separate cpufreq_avg_freq and update it on
    every target() call, but that's overhead...


     \ /
      Last update: 2010-03-23 16:15    [W:0.022 / U:10.492 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site