On Tuesday 23 March 2010 15:23:49 Borislav Petkov wrote: > From: Thomas Renninger <trenn@xxxxxxx> > 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 -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
