Re: [PATCH 5/5] cpufreq: Add support for actual freq

[Thomas Renninger <trenn@suse.de>]

On Tuesday 23 March 2010 15:23:49 Borislav Petkov wrote:
> From: Thomas Renninger <trenn@suse.de>
> 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...


   Thomas