Re: About p4-clockmod breakage/removal

[Len Brown <lenb@kernel.org>]

On Wednesday 14 May 2008, Matthew Garrett wrote:
> On Tue, May 13, 2008 at 11:35:32PM -0400, Len Brown wrote:
> 
> > cpufreq is not designed to manage thermals, and putting p4_clockmod
> > underneath it to manage thermals is a mistake.
> 
> Check processor_thermal.c. It explicitly interfaces with cpufreq in 
> order to perform P state management.

The hook above is so that ACPI thermal throttling
does not invoke T-states until the more  efficient
P-states have already been exhausted.

It doesn't imply the presence of thermal awareness
anywhere in the cpufreq sub-system.

It also doesn't imply that running cpufreq on top
of T-states is a good idea.  Cpufreq as implemented,
say by the ondemand governor, is based
on the assumption that it is running on top of
P-states.  Deeper P-states result in
more efficient operation  (less energy/instruction)
due to their lower voltage, because energy varies with voltage^2.
T-states violate that assumpion and provide
all the performance cost with none of the efficiency
gains of P-states, because energy varies directly
with frequencey -- but so does performance cost.

> > There is already a well known thermal throttling interface
> > available via ACPI and it does not need p4_clockmod to run.
> > Passive trip points work automatically even without cpufreq being present.
> > If they do not, then we need to fix them.
> 
> You're assuming that the throttling interface is always exposed via 
> ACPI. I've seen machines where this isn't the case.

Please show me those machines.

thanks,
-Len