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...?
--
Regards/Gruss,
Boris.
--
Advanced Micro Devices, Inc.
Operating Systems Research Center
--
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
