9.1 Proposal: Power Management (Power++)
Richard A. Smith
richard at laptop.org
Mon Oct 27 17:10:01 EDT 2008
Chris Ball wrote:
> We made an incremental step in 8.2, offering automatic power management
> that is disabled by default, and I propose a talk covering what needs
> to happen for us to be comfortable taking the next step to enable it
> by default in 9.1.
+1. I'm going to expand on this further below. I'm willing to help
research and give the talk. BUT, I have back-to-back competitions on
the 7-9th and 13th-17th plus a fellow dancer from the UK
staying/traveling with me on the 6th-18th. So I'll be pretty scarce
during that period. :)
So any research has to be done prior to that and I won't be available to
help talk unless its held on the 19th.
- Measurement and Tracking tools.
The XO needs to be able to track its own power usage and report back.
This way we can aggregate it all for analysis. Brief discussions in
the 1cc garden have covered a sort of framework for sending arbitrary
data back to the mothership. For this to be effective in most of our
current deployments it also needs to be usable off-line. Ether by
saving up some N number of past logfiles for manual copy and/or
by shipping them off to a school server for later relay.
The data that needs to be tracked can start with the current info that
is tracked by olpc-pwr-log but with less frequency. That will provide
enough information to make general statements of better or worse for
power use and runtime if larger enough sample is gathered. Improving
these measurements to also include things like logging transitions
to/from suspend and various metrics on how much time we we spend in hlt
(C1) vs run (C0) will also be useful. Information on what activities
were running at the time will also be very useful for things like
CPUIdle is our proposed future method on determining when the system is
idle and thus when we can go into suspend. Right now we are using a
pretty simplistic metric which is easily fooled. We need to enable
cpuidle and start using it for our idle detection and start fixing the
cases where its wrong. As of 8.2 cpuidle has make it into the kernel
but unfortunately the code that makes cpuidle work appears to be woven
into the ACPI code which is disabled. So cpuidle does not curretnly
work. Someone needs to investigate this further.
- Workload analysis
The running workload has a pretty large effect on how much power we can
save while the machine is in use. Activities like write and paint have
lots of opportunity for in-use power savings where as activities like
TamTam and Record do not. But there may be things inside of each
activity that can help reduce its runtime needs.
Feedback from the recent presentations of the in-the-field folk say that
popular or highly used apps are Write, Paint, Memorize and Scratch.
These would be good places to start.
- Battery life estimation
Battery life estimation in the face of large power fluctuations is going
to be tricky. While this is not strictly about saving power accurate
representation of what power you have left is desirable. Logs of the
battery life under various scenarios need to be analyzed and models
developed that can be used to estimate how much juice is left based on
previous and current use + some future estimate.
> * setting up multicast groups for wakeup during collaboration
> * exposing a wakeup-timer API in Sugar to allow scheduled wakeups
While I see the usefulness of this I rather see the effort go into
making this not necessary. A dedicated API means that all the apps have
to be modified to take advantage of it. Not sure its fully achievable
since we want to be able to stomp on things like a timer going off every
100mS and suspend anyway if our idle conditions are met.
> * faster resume
This of course is the most crucial part. Very little of the above will
help if we don't speed up suspend/resume to a point where it can happen
transparently below the user at a tolerable level.
As far as I know nobody has yet gone through the process of discovering
just how fast we can go if we do evil hacks with zero regard for kernel
upstream or USB specifications. I propose this is step one. Then try
to figure out how to make it happen so that it plays well with the rest
of the world. IMHO to get where we need to go we will always have to
carry some custom hacks to the USB stack that are outside the standards
but perhaps I'll be pleasantly surprised.
Richard Smith <richard at laptop.org>
One Laptop Per Child
More information about the Devel