Launchpad Entry: kernel-karmic-better-power-mgt
Created: AmitKucheria
Contributors: AndyWhitcroft
Packages affected:
Summary
How can our laptop/mid/netbook survive for a whole day on a single charge? What can we optimize the power consumption of a data center running Ubuntu servers?
Moreever, how can we measure who is consuming all that power.
Also, what is acceptably good, i.e. the level at which chasing the last milli-watt is not worth the cost?
Release Note
Some of the proposed changes might cause regressions if the underlying HW cannot recover from the various power save modes that we might try to force it into.
Rationale
Battery life on Linux is still inferior to Windows running on the same HW. The reason is that there are a lot of use-case-driven optimizations that can be done, but aren't.
User stories
- Alice is attending a conference. Typical of conferences, there are very few power sockets. While listening to the sessions, Alice would like to take notes, check email and then close the lid and go back to listening. She repeats this many times during the day. In order to save battery, the machine should suspend/hibernate when the lid is closed and resume quickly when it is opened. The battery should last the whole day on a single charge.
- Charlie manages a 1000-seat Linux desktop installation. A majority of his users do not power-off their computer at night because they want an instant-on experience in the morning. Some of the more conscientious users suspend the machine, but it still draws some power.
Assumptions
- Everyone actually wants to save power...
Design
First, we need to measure what our various components are consuming.
How to measure?
- measuring raw power consumption with 0 battery externally
- non-interactive powertop?
- recording power information on an ongoing basis may be valuable
- what is the cost of running powertop?
- does powertop work when on power for non-laptop platforms?
- though most of powertop's recommendations are meaningful without the estimate
Measuring in different Target states
There are four main states we expect to consider power consumption:
running
- powertop does a good job of listing the major culprits
- can we improve powertop to make the changes permanent (ie. added to /etc/rc.local) automatically
- could we justify a "i am not knowledgeable, do the common safe things without scaring me?"
- Is there any case for doing this only on laptop? No, servers have the same requirements as laptops. Data center users are especially interested.
- laptop-mode - Should that be default? What about in cases where user is using ext4 that is still likely to cause data loss.
suspended
- do we have individual device control?
- could do individual device shutdown and compare consumption (while running otherwise)
- is there any way to detect antenna or PLLs are 'on'?
- audio amps not turned off, can we tell on the outputs somehow?
hibernated
- should be 0 watts when hibernating
- hard ... any automated wakup is going to cost power
- who is going to hibernate with 5s boot?
power off
- are there any known cases of power off not being total similar to hibernated?
Implementation
Ideas to try in Karmic
- Is is possible to turn off power to the sound chip/amplifiers when user mutes the volume? We could turn it on when user unmutes.
- Same as above with Bluetooth/WLAN in case of users that don't have HW rfkill buttons.
- Introduce a power policy manager (PPM from Moblin?) to allow user to set specific modes on the laptop. git.moblin.org/cgit.cgi/ppm/
- Keep only one network interface powered at any given time. This is what a vast majority of the users want. Advanced users can select two interfaces in Network Manager.
Selective suspend
- Individual devices can be suspended by grokking its /sys file. (find /sys/devices -name power). Does it make sense to do that?
- Might be interesting for netbooks that want to optimize for a particular usecase e.g. 'always-on email'.
UI Changes
Perhaps a Policy Manager UI (a slider?) to allow user to select between Power and Performance. The more the slider is towards Power, the slower it will respond to 'activation'.
Test/Demo Plan
Bug report info
What should we request when a bug of this nature is reported?
- Is there a sane set of data we could get automatically: 'apport-collect power' stylee?
- We should likely make 'Debugging Power' wikipage, with sections on how to use powertop, etc
This need not be added or completed until the specification is nearing beta.
Unresolved issues
This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.
BoF agenda and discussion
- www.lesswatts.org has some mad ideas