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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 23 Mar 2010 15:23:49 +0100
From:	Borislav Petkov <bp@...64.org>
To:	Thomas Renninger <trenn@...e.de>
Cc:	akpm@...ux-foundation.org, davej@...hat.com,
	cpufreq@...r.kernel.org, x86@...nel.org,
	linux-kernel@...r.kernel.org, lenb@...nel.org
Subject: Re: [PATCH 5/5] cpufreq: Add support for actual freq

From: Thomas Renninger <trenn@...e.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...?

-- 
Regards/Gruss,
Boris.

--
Advanced Micro Devices, Inc.
Operating Systems Research Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/