Re: [PATCH, RESEND] acpi-cpufreq: remove unreliable optional device.get() code

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Jul 16, 2011 at 06:49:34PM -0400, Len Brown wrote:
> From: Len Brown <len.brown@xxxxxxxxx>
> Date: Mon, 6 Jun 2011 01:06:57 -0400
> 
> cpufreq offers the optional driver.get() entry point
> for drivers to export instantaneous frequency in
> /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freq.
> 
> 25% of the acpi-cpufreq driver is involved in supporting
> that optional feature, but on modern processors, it
> is not reliable.
> 
> So here we delete this optional feature from acpi-cpufreq.
> /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freq
> will go away on acpi-cpufreq systems, but note that
> /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq
> will still be presnet to indicate the most recent request.
> 
> (and yes, powertop still works:-)
> 
> The most common reason that driver.get() is not reliable
> is that modern processors autonomously change frequency
> without OS instruction.  This means that reading
> PERF_STATUS is possibly in-accurate as soon as the
> instruction after it is read.
>
> Average frequency over an interval is more useful
> than instantaneous frequency on modern hardware.
> acpi-cpufreq supplies average frequency via
> the the driver->getavg() entry, which is what
> the ondemand governor uses.

Regarding this patch and the philosophy behind it, I uphold my doubts which
I specified last time this issue came up (cf.
http://marc.info/?l=linux-acpi&m=130742534931688&w=2 )

Best,
	Dominik
--
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


[Index of Archives]     [Linux Kernel Devel]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Forum]     [Linux SCSI]

  Powered by Linux