> Why can't it be fixed in silicon for future chips? > May there be workarounds possible in the CPU microcode? Not going to happen. > The APERF MSR is not a real > alternative to a real "get current frequency" function (which I have > wished to be added to the ACPI spec for how long? must be close to 10 > years...): APERF only allows you to get an average frequency, and not the > current frequency at the time of the call. Instantaneous frequency can change many times per second. What benefit is there to reporting someting that changes that fast to readers of sysfs? > For silicon which can't be fixed any more, using APERF instead may be a > valid -- but costly[*] -- solution. For other CPUs, I'd favour keeping > the current code -- even if Intel CPUs aren't capable to reliably tell > which frequency they're running at. APERF is expensive how? ondemand, which does care about average frequency, has been using APERF for years. > Finally: > > > + policy->cur = data->freq_table[data->acpi_data->state].frequency; > > How do you know what state / frequency the CPU is running here? really the correct fix is for the upper level of cpufreq to simply no export this value at all, or to export the value that was last written. A driver should be free to decline to supply any current value. thanks, Len Brown, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
