PM Requirements for 2006 - PowerPoint PPT Presentation

1 / 18
About This Presentation
Title:

PM Requirements for 2006

Description:

... a mechanism for implementing this type of constraint on the platform throttling. ... Throttling work loads is a reasonable approach to power management. ... – PowerPoint PPT presentation

Number of Views:21
Avg rating:3.0/5.0
Slides: 19
Provided by: mgr659
Category:

less

Transcript and Presenter's Notes

Title: 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)
Write a Comment
User Comments (0)
About PowerShow.com