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

My previous entry was somewhat misleading in one respect - the discussion of the power consumption of a downclocked processor. The problem is that nowadays, halving your CPU frequency doesn't halve the power consumption (see the figures in Arjan's slides from OSCON last year, for instance). I'm assuming that this is due to the cache size on modern hardware being sufficiently large that it dominates the power consumption of the processor. Dropping the frequency doesn't reduce the amount of power required to keep the contents of the cache alive, so the saving is less than you'd expect. Deeper C states disable the cache and save much more power.

So, if halving your speed means everything takes twice as long but doesn't even halve your power consumption, what's the point in having P states at all? There's a certain amount of latency and power involved in moving between C states, and if the choice is between rapidly cycling between full speed and C4 or just sticking at low speed and maybe dropping into C1 or C2, then executing code at the lower performance state may be beneficial. The ondemand governor takes this into account by looking at the amount of load on the processor over time, so if this doesn't hit a threshold value it'll assume that you're better off staying at the lower performance level.

Syndicated 2008-05-09 15:25:11 from Matthew Garrett

Modern CPUs are great. They have all sorts of advanced power saving features, which is one of those nice cases where everyone can save money, gain performance and claim environmental credentials at the same time. Everyone's a winner.

Well. Everyone's a winner as long as your software doesn't suck.

I've talked about the benefits of the tickless kernels and reducing wakeups and spending longer in deep C states before, so if you don't know about them then go and read that first. This time I'm going to focus on a different level of hardware, and a different level of suck.

For a long time, laptops supported changing the speed of processors when switching between AC and battery. CPU power consumption is proportional to frequency, so dropping the frequency meant a longer battery life. Of course, it also meant that it took longer to get anything done - the reason this was still a win was because CPUs in those days consumed just as much power when idle as when running. Transmeta introduced a technology called Longrun with their Crusoe processors, bringing the ability to drop both the frequency and the voltage of the CPU simultaneously. With power consumption being proportional to the square of the voltage, even a small drop resulted in worthwhile power savings. As the only really worthwhile thing Transmeta brought to the x86 world[1], this was unsurprisingly ripped off by everyone else. Intel introduced their Enhanced Speedstep, AMD gave people PowerNow and VIA have Longhaul.

Obviously, reducing the frequency of the CPU increased battery life. Everyone's happy?

No[2].

The problem is that nowadays, processors don't consume as much energy when they're idle as when they're running. The aforementioned C states mean that an idle processor consumes a tiny percentage of a loaded one - an ultra-low voltage Intel part will draw on the order of a watt. Executing code, even at the lowest voltage and frequency, will draw far more power. Obviously, we want to keep the processor idle for as long as possible. The easiest way to do this would be to never run anything, but that's not a real option. The alternative is to run when we have to, but make sure that we get it over with as quickly as possible so we can return to the idle state. Counterintuitively, that means switching to the highest voltage and frequency, executing the code and then dropping back into the idle state. By going faster, we save power[3].

In summary, the only sensible way to use a CPU is to run it as fast as possible in order to let it idle as much as possible, and drop the frequency and voltage when it's not doing anything. The. Only. Sensible. Way.

Some people write software that lets you choose different power profiles depending on whether you're on AC or battery. Typically, one of the choices lets you reduce the speed of your processor when you're on battery. This is bad. It is wrong. The people who implement these programs are dangerous. Do not listen to them. Do not endorse their product and/or newsletter. Do not allow your eldest child to engage in conjugal acts with them. Doing this will reduce your battery life. It will heat up your home. It will kill baby seals. The sea will rise and your car will float away. If you are already running it, make sure that it always sets your cpufreq governor to ondemand and does not limit the frequencies in use. Failure to do so will result in me setting you on fire[4].

The only legitimate reasons for limiting the speed of your CPU are to avoid overheating (which should be fixed in the kernel, really - having userspace in charge of ensuring the continued functioning of the machine is madness) or to make the machine quieter. And if you want your machine to be quieter, there should be a tickbox marked "Reduce performance in order to reduce noise" or something, which would take into account all the sources of heat in your machine rather than just your CPU. Encouraging the managing of acoustic levels by asking users to restrict the functionality of their CPU is just another way of saying "Look! We suck!". Letting the user choose a specific CPU governor or a specific frequency is not a useful thing to do. Don't do it unless you want to see dead kittens. Delivered by UPS.

[1] And, presumably, whatever else Intel and everyone else ended up licensing off them which resulted in their reinvention as an IP company rather than a CPU one, but that's just not interesting to me.

[2] Even ignoring the people that are unhappy for entirely unrelated reasons, such as injured toenails or the brutal murder of their family

[3] There's a corner case here, which is a system that is always entirely CPU bound. Say we halve the CPU's speed. Along with the voltage drop, that gets us down to about 20% of the original power consumption. Of course, it now takes twice as long to do anything and your screen, RAM, hard drive, chipset and so on are still drawing power, so will end up costing you twice as much power as they would have done if you'd run at full speed. If you do the maths, it works out that you save power if your processor's full-speed power consumption is more than 1.7 times that of the rest of the platform. In the real world, things are made more complicated by the rest of your platform consuming more power if you're working over a longer period of time - your hard drive is going to end up spending more time spun up, your memory bus is going to be active for longer and so on. You're basically not going to hit this case.

[4] While the burning of your body will result in carbon emissions, the reduction in power usage should offset this in the long run

Syndicated 2008-05-08 23:19:14 from Matthew Garrett

One of the advantages of working in a biology lab is getting deliveries of stuff in dry ice and getting to play with the dry ice afterwards. Sadly, while dry ice is clearly very cool (a-ha ha ha ha ha (dies)) it makes a lousy way of cooling down your drinks[1]. With a latent heat of sublimation of merely 199kJ/kg, CO₂ draws less energy out of the liquid than ice's latent head of melting of 334kJ/kg. That's easily dealt with by using larger blocks of dry ice, but the fundamental problem seems to be that most of the sublimed CO₂ boils straight out of the glass and just gently cools the atmosphere instead. Maybe ethanol cubes are the way forward.

[1] Much like Red Stripe, it is also a lousy fabric softner.

Syndicated 2008-05-06 22:48:06 from Matthew Garrett

It turns out that I was insightful four and a half years ago, and I should damn well listen to my own opinions.

Syndicated 2008-05-03 23:50:50 from Matthew Garrett