9.1 Proposal: Power Management (Power++)

[Richard A. Smith]

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 
workflow analysis

- CPUIdle

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