lkml.org 
[lkml]   [2010]   [May]   [27]   [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 Fri, May 28, 2010 at 12:50:45AM +0100, Alan Cox wrote:
    > > That's correct, but to me the Arve's goal is simply to maximize battery life
    > > and he found experimentally that the longest battery life is achieved if
    > > system suspend is used whenever the system doesn't need to be active (from its
    > > user's perspective). This actually is different from "when the system is
    > > idle", because the system isn't idle, for example, when updatedb is running.
    > > However, from the user's perspective the updatedb process doesn't really need
    > > to run at this particular time, it can very well do it's job in parallel with
    > > the user typing or reading news. So, the system may very well be suspended
    > > when updatedb is running.
    >
    > This is where the original questions around QoS came in
    >
    > > Since I think we've now rejected the feature, do we have a clear picture about
    > > what the Android people should do _instead_ and yet keep the battery life they
    > > want? Because I don't think telling "let them do what they want, who cares"
    > > is right.
    >
    > Today "idle" means "no task running"
    >
    > If you are prepared to rephrase that as "no task that matters is running"
    > what would need to answer ?
    >
    > - How do we define who matters: QoS ?
    >
    > - Can you describe "idle" in terms of QoS without then breaking the
    > reliable wakeup for an event (and do you need to ?)
    >
    > Could this for example look like
    >
    > Set QoS of 'user apps' to QS_NONE
    > Button pushed
    > Button driver sets QoS of app it wakes to QS_ABOVESUSPEND
    >
    > That would I think solve the reliable wakeup case although
    > drivers raising a QoS parameter is a bit unusual in the kernel.
    > That would at least however be specific to a few Android drivers
    > and maybe a tiny amount of shared driver stuff so probably not
    > unacceptable. (wake_up_pri(&queue, priority); isn't going to
    > kill anyone is it - especially if it usually ignores the
    > priority argument)

    That should probably go into higher levels, not in individual drivers,
    so we should be able to limit spreading of wake_up_pri() or whatever
    throughout the tree. This particular case should be probably handled by
    evdev raising QoS of the user that is opened particular
    /dev/input/eventX.

    --
    Dmitry


    \
     
     \ /
      Last update: 2010-05-28 02:09    [W:3.761 / U:0.292 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site