lkml.org 
[lkml]   [2010]   [Jun]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
    --- On Tue, 6/1/10, James Bottomley <James.Bottomley@suse.de> wrote:

    > > As long as you can set a wakeup timer, an S state is just a C state with
    > > side effects.

    I've seen similar statements on this endless
    thread before; they're not quite true...


    > > The significant one is that entering an
    > > S state stops the process scheduler and
    > > any in-kernel timers.

    There's a structural difference too, related
    to peripheral device activity and power states.

    Specifically, peripherals can be active in C
    states (erforming I/O, maybe with DMA etc) and
    will in general not be in lowest power states
    (PCI etc). Whereas entry to ACPI S-states
    involves calling the AML code to put those
    peripherals into lowest power modes ... ones
    they can't in general enter at run time. (An
    additional task of that bytecode is to activate
    any wakeup logic, which again is not generally
    functional in except in S-states).


    The point being perhaps more that ACPI doesn't
    map well to the more power-efficient architectures
    (often built on ARM) ... hardware vendors provide
    all kinds of PM hooks, and Linux can choose between
    them so it's more power-miserly than if it tried
    to emulate an ACPI based platform.

    I've seen some Linux systems which put DRAM into
    self-refresh during certain idle modes, for example,
    not just during suspend-to-RAM, if it's known that
    no DMA is active. (Why not save that power if it's
    safe?) Likewise, disable some oscillators and PLLs
    if they're not needed (the clock API allows that to
    be done regardless of "C-states" etc).

    The notion of "suspend" gets introduced on such
    systems primarily to match the ACPI-ish models that
    exist ... rather than because they necessarily make
    good matches for the hardware. Which has left a
    puzzle: how and why to use such "suspend" models?

    Maybe that's underlying some of the pushback for
    the notion of automagic entry to "suspend" states.

    - Dave




    \
     
     \ /
      Last update: 2010-06-01 23:41    [W:0.022 / U:30.288 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site