PM Requirements for 2006

1
PM Requirements for 2006 Overview and
highlights Mark Gross mark.gross_at_intel.com
2
Introduction

• I am the chair or the CELF PM working group.
• CELF is a collection of companies involved with
  CE products that use Linux that want to help
  Linux be more useful for CE applications.
• The current requirements have the following goals
• Represent CE needs to the linux-pm community
• Influence new development
• The document has input from ARM, Intel, Monte
  Vista, Motorola, Nokia, Philips, Sony and some
  input from the Linux-PM list.
• http//tree.celinuxforum.org/CelfPubWiki/CELFPmReq
  uirements2006?actionAttachFiledogettargetCELF
  _PM_requierments2006.pdf
• Linked to at the top of the CELF public PM Wiki
  http//tree.celinuxforum.org/CelfPubWiki/CELFPmReq
  uirements2006

3
Next steps for CELF PM WG

• Take input from PM-Summit
• Coordinate with existing efforts supporting items
  in the requirement document and see what we can
  do to help
• Pick up some of the new ideas and implement /
  submit them for up-stream kernel
• Grow and maintain an open dialog with linux-pm
  community.

4
Requirements document overview

• The PDF requirements document is derived from the
  public Wiki page.
• It includes a subset of the Wiki items that the
  CELF PMWG feels needs attention or looks
  interesting.
• The requirements are partitioned into the
  following categories Interface, Platform
  Throttling, Process / OS Throttling, Lower power
  kernel processing, Sleep state support, System
  Load Prediction, and Measurement and
  Benchmarking.
• Some of the requirements are calls for
  investigations and more data. i.e. Load System
  Load Prediction measurement and benchmarking.

5
Highest priority items for CELF

• The rest of this presentation will be an open
  discussion and walk through of the high priority
  items called out in the document.
• Ill just keep going as time permits )
• Or, we can blow through it all as quickly as
  possible

6
Tick-less idle

• CE devices really need this badly.
• CE platforms will issue special instructions to
  put the SOC power domains into low power modes
  and whenever interrupts happen it wastes a lot of
  power waking these domains up to just increment
  jiffies.
• Think cell phone waiting for call or user to
  press button. The thing is very idle and timer
  ticks prevent us of SOC power saving features,
  which burns battery.

7
Good enough interface for controlling PM knobs

• Today there is not a arch independent / common
  method for controlling anything other than core
  frequency.
• I believe this is because of the implicit
  influence of ACPI on assumptions made by the
  CPUFREQ infrastructure.
• CE archs are constantly rolling there own
  platform control drivers, doing some custom thing
  or using an OSV only solution (DPM)
• This is sub-optimal.
• The CE-platform developer has no choice today if
  they want to do power management today they need
  to use non-mainline solutions.
• How can we design a platform independent
  interface to sometimes arch specific controls?
• Do we provide some extensibility to the
  cpufreq_driver structure?

8
Design Goals for PM frameworks

• Enable policy drivers / interfaces for setting
  platform dependent control variable.
• Extensible WRT platform specific control
  variables.
• Policy drivers need to be arch-independent as
  far a the kernel build is concerned, but
• Policy drivers that control platform specific
  parameters not available at load time, should do
  no harm.
• Perhaps use compile time and kbuild to control
  the policy driver options that are built to avoid
  building such drivers?
• No implicit constraints on policy algorithms or
  logic.
• Keep policy implementation in user space, or
  policy drivers
• Platform constraints on control variables are
  enforced by arch code

9
Struct cpufreq_driver needs to export core Voltage

• Most CE platforms can change both frequency and
  Voltage. i.e. K(OS_State, freq, volt) ? (freq,
  volt)
• CPUFREQ implicitly assumes that voltage can be
  computed from Frequency. i.e. K(OS_state, freq) ?
  freq
• This interface constraint locks out entire
  classes of power management opportunities for CE
  products without using custom patches.
• This interface constraint is likely the reason
  for the limited numbers of CPUFREQ governor
  options today.

10
Reducing timer tick overhead

• For CE devices much of the default kernel
  periodic processing is not helpful and burns
  power.
• Efforts to quantify or measure the work done on
  timer ticks in a running system would be very
  helpful.
• Efforts to trim down the work done on timers for
  CE platforms is also of high value

11
High latency Idle state machine

• CE platforms tend to have multiple low power idle
  states, where different components on the SOC die
  are powered off or put in an ultra-low power
  state.
• The problem is that these ultra-low power states
  is that they have significant latency.
• The problem is not simply choosing which idle
  function to call from the scheduler. Its doing
  so in a sane manner without hosing the system.
• Consider having a set of 5 idle functions you
  could call. Each one with a different latency,
  sorted in order of increasing latency. i1,
  i2,i5 Where i5 has a 3sec latency.
• How could such idle functions be used, without
  sacrificing the usability of the system?
• You cant simply call i5, from idle every time.
  Rather you would likely set up a one-shot call to
  i5, where upon the next call to idle the system
  needs to consider the lower latency idle
  functions first.
• Further how could one export the idle function
  policy controls to user space?

12
CPUFREQ Governor limiting

• Using some CPUFREQ governors can lead to issues
  with media play back.
• CE devices would like to see maximum platform
  throttling subject to the constraint that RT play
  back of media not drop frames.
• There needs to be a mechanism for implementing
  this type of constraint on the platform
  throttling.
• One idea to implement this capability is to
  provide a deadline governor, that takes a
  periodic deadline and regular heartbeat into from
  a mplayer type of application.
• As the application finishes with a frame of
  compressed media it heartbeats the governor.
• If the heartbeat comes too close to the deadline,
  then throttle up the platform, otherwise throttle
  back.

13
BACK UPin case there is time for more

• The following are items worth further
  investigation.

14
Measurement and Benchmarking

• We are missing well defined / published processes
  and techniques for measuring the effectiveness of
  PM techniques. We could use some type of project
  to provide these.
• We need work load and benchmark scenarios for
  evaluating and driving PM feature development.
• coffee shop workload scenarios
• Airplane workload scenarios
• Cell phone workload scenarios
• PDA workload scenarios
• Set-top box workload scenarios

15
PM / scheduler coupling

• Throttling work loads is a reasonable approach to
  power management.
• Many user scenarios call for closer interaction
  between the scheduler and power management.
• Running cron jobs while under battery isnt cool.
• Asymmetric suspend / resume support for selected
  tasks.
• Think running a large cross compile or
  transcoding mp3s to orgs, while tethered,
  suspend system, go to the coffee shop, use the
  system for a while without burning battery on the
  background processing, and to have the processing
  continue when re-tethered seamlessly.

16
Suspend resume latency and VM thrash

• Todays suspend / resume processing is not very
  predictable in terms of the time it takes for the
  system to return to a useable state, capable of
  playing back media.
• One problem is the predicability is very poor
• One problem is even after the UI is up and mostly
  responsive, the ability to play back media is
  delayed by the thrashing of the VM refreshing
  pages that where freed on the suspend operation.

17
Need to avoid implicit ACPI assumptions in APIs

• CPUFREQ is guilty of this in that it assumes core
  voltage is a function of frequency. Which is not
  true for most platforms without ACPI.
• Its been getting better. Swsusp no longer uses
  echo s4 gt /proc/acpi/sleep
• Architecture maintainers need to export more
  platform throttling interfaces before this
  problem sorts itself out.

18
(No Transcript)