Observations on power management

CPU

• The "powersave" and "performance" CPU governors in the Linux kernel are misleadingly named. Powersave will generally not save you energy. Performance will generally not provide you with extra performance. The reasons for this are slightly counterintuitive.

  Modern processors implement runtime power saving modes called "C states". Each of these states is denoted by the letter C followed by a number. The larger the number, the deeper the C state and the more power that state saves. In a deep C state the majority of the processor will be unclocked and powered down, reducing the CPU power consumption to a very low level.

  C states offer significant power savings, but cannot be entered when the CPU is executing instructions. The best power savings can be obtained by running the CPU as fast as possible until any outstanding work is completed and then allowing the CPU to go completely idle. The powersave governor will extend the time taken to complete the work and reduce the amount of time spent idle. On any modern CPU the benefit of carrying out the work at a lower clock and voltage will be outweighed by the loss of the idle time. In almost any workload, powersave will consume more energy than any other option.

  The ondemand governor jumps the processor to full performance once demand reaches a certain threshold. It then drops back to lower performance states when the work is exhausted. This allows a return to idle in as short a timeframe as possible. The reason to prefer ondemand over performance is that very short bursty workloads will prevent the CPU from entering deep C states anyway, but do not generally benefit from being run at the higher CPU speeds. Not raising the processor clock for this workload can save some energy.

  The conservative governor behaves like ondemand but takes longer to switch states. This will almost always result in it taking longer for the processor to become idle, thus increasing power consumption.

  Summary: Use ondemand. Conservative is a valid option for processors that take a sufficiently long time to switch performance states that ondemand will not work.

  Note: There are some workloads which currently interact poorly with the default ondemand settings. If you find one of these workloads, please contact me.

• The p4-clockmod cpufreq driver does not alter the voltage of the processor. It technically does not even reduce the clock frequency. Instead, on some percentage of clock cycles the processor is halted and then allowed to proceed on the following cycle. This is intended to reduce the heat output of the processor. It is not usable as an energy saving mechanism. A 50% reduction of the CPU throughput will not result in a 50% energy saving. Any job running on the processor will now take twice as long and will consume more energy overall.

  Summary: Don't use p4-clockmod except to prevent processors overheating

• Deeper C states save more power but take longer to enter and exit. Doing small amounts of work frequently makes it difficult to enter these deeper states and so costs more energy than doing the same amount of work in one go.

  Summary: Attempt to batch work. Decode multiple frames into a buffer and display them rather than attempting to decode each frame just in time.

• Some systems have poor cooling mechanisms and so may overheat under heavy CPU load. One common attempt to work around this is to limit the maximum speed of the processor in order to reduce its heat output. However, this prevents the processor from running at full speed even when it's not in danger of overheating. This will result in it taking longer for the CPU to enter idle states, ironically resulting in it becoming hotter than neccesary and consuming more energy.

  Summary: If users need to perform thermal management of their systems, write an application that monitors the temperature and limits the CPU speed appropriately. Don't attempt to perform thermal management by using power management functionality to statically limit the processor frequency.

Graphics

• The hardware used to display a static image on the screen is the same regardless of whether the image was generated with the graphics card's 2D or 3D hardware. Regardless of the number of graphical effects used on the desktop, the common case is for the desktop to be static. Composited and traditional desktops will generally consume the same amount of power.

  Summary: Don't offer the choice of disabling compositing when on battery. It reduces functionality for no power benefit.

• A black screen takes up as much power on a TFT as a white one. A screensaver that draws a black screen saves no power and does nothing to protect the screen.

  Summary: If the user has not requested an animated screensaver, turn the screen off immediately rather than drawing a black screen.

• Displaying an image on screen requires copying that image out of graphics memory. Each memory access takes a certain amount of energy. Reducing the amount of memory to be accessed is a good thing from a power management perspective. Some modern graphics chipsets (including just about any recent one from Intel) support a mode where the contents of the screen are compressed in memory. The compressed copy can then be read, saving energy. The mechanism for this is generally a trivial run length encoding of the screen contents on a line by line basis. Continuous horizontal blocks of colour will compress well, while horizontal gradients will not.

  Summary: Try to design desktop backgrounds with vertical gradients rather than horizontal ones.

• Another approach to reducing the amount of memory access is to reduce the number of times the screen is updated per second. Higher screen rates reduce flicker and blurryness when obects are moving, but a static screen can be updated less often and save power. Static screens also allow the graphics chipset to be underclocked, saving more power.

  Summary: Try to avoid anything that unnecessarily updates the screen.

Hard drives

• Hard drives consume significantly less power when spun down. However, spinning a hard drive back up results in a larger power draw and can reduce the lifespan of the drive (most drives are only rated for a certain number of spindown/up cycles). The common approach to this is a user-definable static timeout. Setting too low a timeout means that the drive will spin down too often, resulting in the user having to wait for it to spin back up, more energy being consumed and the drive's lifespan being reduced unnecessarily. Setting too high a timeout means that the drive will be spinning even when not necessary, wasting energy. "Too low" and "too high" depend on the current workload and may change over the course of a day.

  Summary: Don't implement a static spindown timeout. Use a dynamic learning algorithm that adapts to the user's access patterns.

• Seeking takes more power than simply reading a linear set of blocks off a drive. It also kills performance - even a high spec drive will be unlikely to be able to perform more than 150 seeks a second.

  Summary: Avoid unnecessary file accesses and seeking within files. Try to use single large files rather than multiple small ones.

• Traditional unix semantics require updating the atime of a file every time it's read. Disabling atime updates can confuse some applications that depend on the ability to determine whether the user has examined a file since it was last modified. The relatime filesystem option only updates atime if the previous atime was before the file was last modified. Reducing these writes makes it easier to keep drives spun down.

  Summary: Use relatime on filesystems when possible.