As noted in the comments here, one reason to forcibly slow down the CPU on a system (and waste power in the long run) is to deal with cases where failing to do so can result in the machine overheating. Part of the problem is that Linux still tends to be less power efficient than Windows, and so various components will be generating more heat than when the machine was tested. The ACPI spec includes support for passive cooling of processors, which allows the system to reduce heat generation by slowing the CPU down. The problem is that not all vendors include a passive trip point in their firmware, and in the absence of one Linux will happily let the temperature rise until it hits a critical level and the machine shuts down.

I've written a patch that generates a passive cooling trip point if your firmware doesn't provide one. Since there won't be a firmware event when the temperature crosses the trip point, it also forcibly enables polling (the spec actually requires this, so I've no idea why Linux doesn't do it anyway). The default polling interval is quite long - you can adjust it in /proc/acpi/thermal_zone/*/polling by just echoing in a value in seconds. I've gone for a long delay in order to reduce any possible power consumption issues caused by this, but in the long run I'd like it to reduce the polling interval if the temperature trend is upwards and increase it again if the trend is downwards.

The patch makes the assumption that you're never going to get within 5 degrees of the critical temperature in normal use, which I think is pretty reasonable. The probability that the machine will reach equilibrium at that point is fairly small, so if you get that close you'll almost certainly end up with a powered down machine unless we do something about it (like forcibly downclocking your CPU). I don't have any affected machines, so I've only been able to test it by artificially lowering the trip point - if people find that it still lets the processor get over temperature without attempting to slow it down first, then I'll probably need to implement the more advanced polling policy.

In any case, I'm interested in feedback.

Syndicated 2008-05-14 01:27:20 from Matthew Garrett