In the last few days I’ve been working with Auke Kok on adding some new features to the PowerTOP tool.
There are three new power saving checks in the current git version of PowerTOP. Each feature needs a small kernel patch to give PowerTOP the information it needs; the three patches are currently making their way through the various maintainer trees and code reviews, hopefully for inclusion in the 2.6.33 kernel.
Test 1: Who is spinning up the disk
Not everyone has an SSD in their system yet (I feel sorry for those who don’t). The mechanical rotation of a disk seems to cost in the order of 0.5 Watts to 1 Watt of power (depending on the disk).
For this reason, pretty much all laptop disks will stop spinning after several seconds of inactivity.
Now, to enjoy this power savings, it is essential that the disk gets to actually spin down, that is, that there are long periods of inactivity. In a typical Linux distribution, there are various programs that, unfortunately, write things to the disk all the time. Until now, the only way to find out which programs were doing this was to use the blockdump kernel feature.
blockdump is not very user friendly, and while powerful, has several caveats.
Using the perf kernel infrastructure, the git version of PowerTOP now has included the equivalent of the blockdump feature, and will report disk-waking application both in the regular interactive
view as well as in the diagnostic “dump” mode.
In the interactive mode, disk activity is shown with a “D” in the line like this:
Top causes for wakeups:
5.9% (441.0) <interrupt> : ahci
0.0% ( 0.0)D gcc
and in addition, a suggestion will show up in the bottom pane like this:
The program 'cc1' is writing to file '.oom_kill.o.d' on /dev/sda3.
This prevents the disk from going to powersave mode.
While in the “dump” mode a full list of file accesses is shown:
Disk accesses:
The application 'gcc' is writing to file 'ef7f9d8f6d628ba196edb8882ed560-' on /dev/sda3
The application 'gcc' is writing to file '?' on /dev/sda3
The application 'gcc' is writing to file 'sysctl.o.BvmMr0' on /dev/sda3
We used this feature to make sure that the Moblin OS keeps the disk in low power mode as long as possible.
Test 2: Is the audio power saving working
PowerTOP has been suggesting to enable the power saving feature of the HD Audio chipset. In power save mode, the so called “codec” (the chip that turns the digital signal into the analog voltages that speakers can then turn into sound) will be turned off during periods when no applications use the sound subsystem. This can easily save 0.25 Watts to 0.5 Watts.
However, as usual, this savings is only achieved when no application is actually using the sound subsystem. The git version of PowerTOP will now show statistics
about how much of the time the audio codec is in power save mode.
In dump mode, the output looks like this:
Recent audio activity statistics
Active Device name
0.0% hwC0D2
while equivalent information is shown as a suggestion in interactive mode if there is activity on the audio chip.
Test 3: Is SATA Link power management working
PowerTOP has checked the ALPM AHCI Link power saving feature for quite some time now. This feature is good for between 0.5W and 1W of power per Serial ATA link
when the link is quiet. Now, of course this is only helping if the link is actually quiet….
The git version of PowerTOP will now display actual statistics of the various Serial ATA links in the system to measure the effectiveness of this feature,
as well as pointing out potential tuning spots.
In dump mode, on a busy system this will look like this:
Recent SATA AHCI link activity statistics
Active Partial Slumber Device name
86.5% 13.5% 0.0% INTEL SSDSA2MH08
While on a more idle system it looks like this:
Recent SATA AHCI link activity statistics
Active Partial Slumber Device name
0.8% 99.2% 0.0% INTEL SSDSA2MH08
In interactive mode, the same information will be displayed in the suggestion portion of the screen.
I expected that my snd_hda_intel driver would be going into power save mode by default, but reading this article I verified the options to the module and noticed it says:
—-
power_save_controller:Reset controller in power save mode.
power_save:Automatic power-saving timeout (in second, 0 = disable).
—-
So I wonder how I could verify that it is in fact enabled. I have no options provided to the snd_hda_intel driver so it is using whatever default is set.
If it is not enabled, what would be good settings to use ?
With the latest PowerTOP code and the patch from the ALSA tree.. no need to guess. you can now KNOW.
I wonder what are the worst offenders apps on an idle Fedora system with the default configuration. May be there are bugs filed already. It would be great if you could do some quick analysis on this for us the mere mortals who can’t get all of this amazing work in our systems (just yet).
Excellent work Arjan and Auke!.
[...] Via | FenRus [...]
[...] Via | FenRus [...]
[...] Some PowerTOP updates In the last few days I’ve been working with Auke Kok on adding some new features to the PowerTOP tool. [...]
Slightly offtopic, but what would be the best way for an application to wake up without using an alarm/timer. PowerTOP reports wakeups, but is it possible to have a function called badsleep() that wakes up when some part of the system makes a noise? So if PowerTOP would report “Wakeups-from-idle per second : 30.8″, the average sleep time of badsleep() would be about 30ms.
badsleep() would allow applications to have regular opportunities for activity without causing extra wakeups-from-idle.
Arjan, I read that as a “no, you cannot find out on older kernels that lack the ALSA patch”. I guess running an Enterprise distribution doesn’t help at all
But what values for both options may help the most when you want this enabled and get the best result ?
It would be nice as a user/system engineer if we could query the value of kernel module options on a running system in /sys. I don’t think that is currently possible, is it ?
The application can use the range-timer feature to set a timer when it wants the event, with a really long slack value; this will cause the Linux kernel to wake the app up together with other events.
[...] van de Ven reports on new PowerTOP features on his blog. The new features live in the PowerTOP git repository and require small kernel patches [...]
[...] Via | FenRus [...]