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 -- 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
