lkml.org 
[lkml]   [2010]   [May]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
    From
    On Fri, May 28, 2010 at 8:06 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
    >> Arve points out that qos constraint objects could work (but not if
    >> specifically tied to apps): http://lkml.org/lkml/2010/5/28/120 though
    >> he suggests that "latency" constraints don't represent this as well as
    >> "state" constraints.
    >
    > With latency you have an "I don't give damn" latency in your model which
    > we could describe as infinite or "manyana" perhaps.

    I think Arve's concern was the representation of the "I care, but only
    a little" or "just low enough to ensure threads must run" level which
    is what suspend blockers would map to (low enough to ensure we
    shouldn't halt the world but not necessarily implying a hard latency
    constraint beyond that).

    >> Though if you look at it that way, then suspend_blockers become qos
    >> constraint objects, but their implementation and usage remain pretty
    >> much the same as we have now, which does not address Alan's concern
    >> regarding code turning up in drivers, etc.  I'm not sure how you can
    >> solve this problem (avoiding races around entering/exiting the suspend
    >> or suspend-like state) without having a means for drivers to prevent
    >> entry to that state.
    >
    > I am much much less concerned about general expressions of constraint
    > appearing in drivers. One of my early mails gave a list of other
    > people/projects/problems that need them - from hard real time, to high
    > speed serial on low end embedded to virtualisation.
    >
    > They fix a general problem in terms of a driver specific item. We end up
    > making changes around the tree but we make everyone happy not just
    > Android. Also we are isolating policy properly. The apps and drivers say
    > "I have these needs", the power manager figures out how to meet them.

    That makes sense -- and as I've mentioned elsewhere, we're really not
    super picky about naming -- if it turns out that
    wakelocks/suspendblockers were shorthand for "request a qos constraint
    that ensures that threads are running", we'll be able to get things
    done just as well as we do now.

    > Where it gets ugly is if you start trying to have drivers giving an app a
    > guarantee which the app then magically has to know to dispose of.

    Yeah -- which is something we've avoided in the existing model with
    overlapping wakelocks during handoff between domains.
    - input service is select()ing on input devices
    - when select() returns it grabs a wakelock, reads events, passes them
    on, releases the wakelock
    - the event subsystem can then safely drop its "should be running
    threads" constraint as soon as the last event is read because it has
    no queues for userspace to drain, but the overlapping wakelock
    prevents the system from immediately snapping back to sleep

    > If you are prepared to exclude untrusted apps from perfectly reliable
    > event reporting (ie from finger to application action) that doesn't seem
    > to be a neccessity anyway.

    Currently in the Android userpace only trusted (system) apps can
    directly obtain wakelocks -- arbitrary apps obtain them via rpc to a
    trusted system service (which ensures the app has been granted
    permission to do this and tracks usage for accountability to
    user/developer).

    Brian
    --
    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 17:15    [W:4.133 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site