tagline: From openSUSE
- 1 Introduction
- 2 What is done
- 2.1 CPU Frequency scaling (ACPI P-States)
- 2.2 Fixing bad userspace
- 2.3 Multi-Core aware CPU scheduler
- 2.4 Displays
- 2.5 Storage Devices
- 2.6 Wireless Networking
- 2.7 Sound Cards
- 3 What can be done better
- 4 What is not done
- 5 References or... useful information
The following sections will give an overview about power management in SUSE Linux based products. That is, either openSUSE 11.1/Factory or SUSE Linux Enterprise 11. It will provide an overwiew about what is done to extend battery run time on notebook computers.
The two main frameworks in place for doing so are pm-utils and the laptop-mode-tools. General power saving functionality which will get activated when the main AC power is plugged is done with pm-utils. It's scripts live in /usr/lib/pm-utils/power.d and get manually activated when 'pm-powersave true' is executed.
laptop-mode-tools has it's configuration in /etc/laptop-mode/laptop-mode.conf and has a lot, yes, a lot, of possible settings for influencing hard disk or filesystem operation.
What is done
CPU Frequency scaling (ACPI P-States)
The performance states of a CPU (according to the ACPI specification) alter the clock frequency the processor core can operate with. That is, how many instructions per seconds it can execute. This feature is widely known as CPU frequency scaling. Examples for such technologies are Intel SpeedStep or AMD PowerNow. Modern operating systems are using this to adjust the frequency on the fly, increasing it when there is heavy work to do, lowering it as soon as there are only tasks which do not need much CPU support.
This is in place by default on SUSE based products such as openSUSE 11.1, openSUSE Factory or SUSE Linux Enterprise Desktop/Server. The default CPU frequency scaling governor in the kernel is called 'ondemand' and which cares about adjusting the frequency in a dynamic way. This does not need manual intervention from userspace.
Why is there no GUI for changing the CPU Policy (CPU governors)?
From my experience, customers, business such as openSUSE users, often only look for such options because they were present in the past (test plans etc.). This maybe was a mistake in the first place on our side.
We should really get our customers to know that it doesn't make sense to choose a static CPU frequency scaling algorithm such as powersave or performance.
Using the 'powersave' governor won't give you any power savings at all. When the CPU is limited to its lowest frequency, the duration of the executed tasks is just longer which results in the same power consumption in the long run. Modern notebook components like CPUs are optimized to have a very low power consumption when they're idle. So the main goal should be to have the system being idle as long as possible/most of the time. When a task runs longer, all the other components like display, hard disk, network components can't go to an idle state during that time, too.
For the 'performance' governor, users won't even notice the performance gain. Modern CPUs and the kernel's CPUFreq implementation are able to switch frequencies very fast. But if you're running at the highest frequency all the time, the system will always waste a lot of power during idle periods.
There are corner cases where the above doesn't apply, but those mainly only apply to the server area. It's not good to give the common user control over something that looks like "yeah, choosing that will give me more performance or more power savings" in an easy way, without them knowing the background information or the overall impact on the system. That's why we chose to remove those CPU frequency settings from the GUI. Very advanced users still can make use of command line tools like the cpufreq-utils.
In the end, this doesn't mean we're not doing something in regard to power management at all. It's just that most things are done dynamically these days. When a specific component is idle, it shall consume as little power as possible. If there's something to do, complete the task as fast as possible to be able to go to sleep afterwards. A widespread buzzword for this whole strategy is "Race to Idle".
Fixing bad userspace
During the last couple of years, a lot has been done with fixing bad userspace applications. In this context, bad userspace means processes/applications which unnecessarily wake up the CPU although it can be avoided. Userspace waking up the CPU less often automatically means that it can be put into idle mode more often, resulting in a lower power consumption. This is of course an ongoing process. Guilty applications can most often identified by Powertop.
Multi-Core aware CPU scheduler
The Linux kernel has a multi-core aware CPU scheduler. Dumbed-down, that means that the CPU load is scheduled in such a way only one CPU is woken up, if possible.
The setting can be changed from userspace and is done via pm-utils:
$ echo 1 > /sys/devices/system/cpu/sched_mc_power_savings
The display power policies are carried out by the gnome-power-manager applet in GNOME or the power-devil in KDE4.
DPMS methods are used to disable the monitor/display after a specific time when the system is idle.
The display brightness is adjusted according to the state of the system. Then it runs battery powered, the brightness is reduced, when running connected to the AC power, it is increased.
Furthermore, gnome-power-manager even dims the display after a specific idle period, increasing it again when there's user activity.
SATA: Aggressive Link Power Management (pm-utils)
The SATA link to the disk is put into low power mode when there is no IO. It is automatically woken up when requests arrive. This can save up to around 1 W per disk.
File Access Time (atime)
As with the CPU, the goal is to wake the disk as seldom as possible. To archive that, filesystems are mounted with the 'relatime' option. This option only updated the last access time of a file if the old access time (atime) is older than the modify time (mtime) or the change time (ctime). For the reasoning why we don't use the 'noatime' option, please see below.
When running on battery, we also make use some kind of laptop-mode to make use of caches through the laptop-mode-tools. To extend the time of inactivity, the kernel buffers data as long as possible to prevent the disk to spin up too frequently. However, this brings along the danger of data loss abrasion. Hard diskswhich come into operation in desktop PCs are often not designed to spin up and down frequently. This might shorten their lifetime. The same danger exists for laptop disks, however, not to the same extend. Manufacturers often construct their mobile disks to be prepared for frequently going to a low power mode and waking up again. In contrary to that, laptop disks do not contain that much potential of saving a lot of power when in standby or sleep, often they are already optimised for a low power consumption.
When the wireless LAN standard IEEE 802.11 was designed, the IEEE 802.11 working group already had power management in mind. That makes it possible to put the wireless chip to sleep. Currently supported are Intel chips like IWL3945 and IWL4965.
The first precondition is to know that the most power of wireless cards is spent during data transmission times. As a logical consequence, the aim should be that there shall only be short heavy burst of transmission, so that connected clients are able to go to sleep immediately after the data was submitted. So clients find themselves in two states. One for transmission of data, the active state, and one where they are sleeping. Clients periodically wake up, checking if there is some data intended for them available. In turn, the access points (those which support it) are aware of the state of all connected clients, whether they are sleeping or active. If there are data packets for one specific client, and this client is currently in an active state, the packets are immediately delivered. If the client is sleeping, packets are buffered until the client wakes up the next time.
This can save up to 2 W! Adjustments from userspace can be done with:
$ echo 6 > \ /sys/bus/pci/drivers/iwl*/000*/power_level
In SUSE Linux based products, this is done automatically with pm-utils when transitioning to a battery powered mode.
Sound cards can be shutdown (put into a low power mode) when not playing any sound. This is done after a certain idle period has passed.
Power savings: ≈ 0.5Watt
The timeout can be adjusted from userspace and is automatically done via pm-utils:
$ echo 10 > /sys/module/snd_hda_intel/parameters/power_save
Why is there sometimes a clicking noise on my system?
When coming out of the low power mode, some hardware produces a clicking noise. This can either happen when plugging/unplugging the power cord or immediately before a sound is played.
If this gets too annoying, it can be disabled with:
until OpenSUSE 11.2:
$ echo SOUND_PM= > /etc/pm-utils/sound-pm
for OpenSUSE 11.3: change the following setting in /etc/laptop-mode/conf.d/intel-hda-powersave.conf
What can be done better
Graphics card power management
The potential in this area is quite big. However, the possibilities are even smaller.
For the chips where there exist open source drivers like Intel, the chip is quite smart in regard to power management already. There is not much that needs to be done here.
fglrx: aticonfig exports some functionality to adjust power management modes of those graphic cards. However, we do not make use of them, hesitating if we should.
radeonHD: Due to the fact that this driver is quite new, it doesn't yet support power management functionality. This will hopefully be fixed in the future.
- NVIDIA: TODO
'noatime' filesystem option
We remount filesystems with the relatime option when running battery powered. However, there's even a better possibility to save power, the 'noatime' option which causes the filesystem to never write any access time which in turn keeps the disk idle for a longer time. The reason why we don't do this is that some applications need a stored access time to work properly. In fact, the only application I know of is the mail reader "mutt". So if you're not using it, e.g. your using evolution or the like, you might happily change your system to use the 'noatime' option. This can be done with adjusting the following settings in /etc/laptop-mode/laptop-mode.conf:
CONTROL_NOATIME=1 USE_RELATIME=0 # (default in SUSE based products is USE_RELATIME=1)
Furthermore, laptop-mode-tools contains a lot more settings which can help to save power. The comments in /etc/laptop-mode/laptop-mode.conf should be quite self explanatory but need some basic knowledge about disk and filesystem power management.
USB power management
A feature not yet implemented is USB power management. This is currently work in progress. With this feature, active USB devices are automatically deactivated when not used. A good example where this makes sense might be a web cam. However, this cannot be set on all systems and all devices automatically. A whitelist is needed, which makes the implementation a no-one-liner.
For activating it, userspace can write to the sysfs files in /sys/bus/usb/devices/*/power/level for each individual USB device like that:
for dev in /sys/bus/usb/devices/*/power/level; do echo auto > $dev done
This can save up to about 2 W, depending on the hardware in use. You can enable laptop-mode-tools to control this by editing /etc/laptop-mode/conf.d/usb-autosuspend.conf.
Wired networking (LAN)
With some network cards, there is the possibility to reduce the link speed in times of low traffic. However, a proper implementation for a dynamic adjustment still has to be done.
Please also note: This has not been tested by us if it saves any power at all. It might also heavily depend on the hardware in place.
For drivers which have the 'ethtool' extension, this can be done with:
$ ethtool -c <interface name> speed <speed>
ethtool -s eth0 speed 10
Better Killswitch Management
Modern laptops often export a variety of killswitches for bluetooth, WLAN oder WWAN. When running battery powered, often only one makes sense to be activated. Most devices activated although unused will consume power from the battery. Currently the most problematic part often is the bluetooth device. It consumes up to 1 Watt of power although you might don't even need it for several hours. So turn it off through the bluetooth applet (KBluetooth or Gnome's bluetooth-applet) or a killswitch applet (Killswitch-Manager or killswitch-applet)!
In future, it would be nice to adjust the state of the killswitch depending on the user's settings, or even have it dynamically activated/deactivated when needed/unused. But we're not there yet. However, you can enable laptop-mode-tools to control this by editing /etc/laptop-mode/conf.d/bluetooth.conf.
What is not done
CPU throttling (ACPI T-States)
While this can be useful for systems which tend to overheat, it is not an option to save power. Most hardware itself (CPUs) has a good overheat detection and are doing throttling on their own when a certain temperature is reached.
The main reason behind why the operation system (kernel/userspace) is not doing it is that throttling doesn't give you any power savings. The CPU just skips some clock ticks without actually reducing the frequency. It just makes the system slow which in turn means that tasks require more time to finish up keeping the whole system busy. Don't do that on your own!