Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

Dmitry Torokhov
2010-05-28T00:06:54Z

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