| 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
| ||
|
Date: Mon, 10 Feb 2014 12:47:12 -0800 From: Andy Lutomirski <luto@...capital.net> To: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Naga Chumbalkar <nagananda.chumbalkar@...com>, cpufreq@...r.kernel.org, linux-pm@...r.kernel.org, "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>, Dirk Brandewie <dirk.j.brandewie@...el.com> Subject: What should cpuinfo_cur_freq mean? There are least three choices for what the "current frequency" is: 1. The frequency that the cpufreq driver thinks it has requested. This shows up in scaling_cur_freq. 2. The frequency that is actually programmed into the CPU. This is what acpi_cpufreq's cpuinfo_cur_freq reports. 3. A measurement of the number of cycles per unit time that are currently or recently happening. This is what intel_pstate reports. The fact that acpi-cpufreq and intel_pstate behave differently here is unfortunate. I have servers [1] with broken BIOS that occasionally screw up the requested P-state (i.e. MSR 0x199). With acpi_cpufreq loaded, I can at least tell that there's a problem by reading cpuinfo_cur_freq. With intel_pstate loaded, I get a rapidly fluctuating value that depends on Turbo's current mood. Can we separate out these concepts into separate sysfs files? [1] These are fully up-to-date, recent generation Dell servers. -- 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/
Powered by blists - more mailing lists