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 cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
