lkml.org 
[lkml]   [2010]   [May]   [28]   [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)
    > This is a much harder question to answer that what we need to use
    > opportunistic suspend. The question we ask is more like this: "Is all
    > important work complete?". In the simplest case these can be the same,

    I don't believe you can answer that question without telepathy and a
    crystal ball.

    The application doesn't know because it has no idea how to balance
    conflicting resource demands or to infer the users requirements and
    wishes. Most apps will misbehave anyway.

    The OS doesn't know because it cannot tell what the app wants

    So at best you have a heuristic.

    > What happens if the user presses the button right before you set QoS
    > of 'user apps' to QS_NONE?

    Read down a paragraph.

    > To me it looks like this solution would result in this sequence which
    > may ignore the button press:
    >        Button pushed
    >        Button driver sets QoS of app it wakes to QS_ABOVESUSPEND
    >        Set QoS of 'user apps' to QS_NONE
    >
    >
    > >        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)
    >
    > Why is "wake_up_pri(&queue, priority)" more acceptable than "suspend_block(..."?

    We keep it kernel side
    It expresses policy and wishes rather than enforcing a behaviour.

    What for example does "suspend_block" mean on a virtual machine ?

    I would prefer "priority" was some kind of resource constraint model
    instead but I'm just trying to think how to be absolutely minimally
    invasible at this point.

    > What happens if the button press happend before this line:
    > >        count2 = tasks to QS_NONE | QS_NOTCHANGED
    > >        Screen off
    > >                                        Button Press
    > >                                        task to QS_ABOVESUSPEND
    > >        count = tasks that are QS_NOTCHANGED to QS_NONE
    > >
    > >        if (count != count2) {
    > >                Stuff happened ... rethink
    > >        }
    > >
    > > That is still a bit weird and wonderful but all the logic is in the right
    > > places. The special magic remains in the Android policy code and in the
    > > kernel specifics for Android.
    > >
    > > Thoughts ?
    >
    > I don't think it works. Also, it does not seem much less invasive than
    > suspend blockers.

    "I don't think it works" isn't that helpful. I don't think it works
    because .. would help me a lot more.

    I think it's a loss let invasive because you are not exposing a ton of
    stuff to user space in general (just some private chit chat between a
    couple of processes). I would prefer it didn't even do that but simply
    used QoS guarantees. However I don't see a way to achieve that given your
    intended QoS guarantees change according to actions like screen off.

    Alan
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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