[lkml]   [2010]   [May]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
    > That's the point -- suspend does not evaluate the system state 
    > correctly because it doesn't have the necessary information. Suspend

    The power management layer knows if the machine is idle, it has insight
    into when the next wakeups will occur.

    > blockers are a way of providing it that information. They don't paper
    > over the problem; they solve it.

    I'm still unconvinced (see Thomas examples as a starter) and even if they
    did, the cure would be far worse than the disease.

    The hardware world also shows how you handle suspend/resume event races
    cleanly and in turn how we can handle right from user to hardware.

    If you are dealing with a well behaved UI app then its event loop will
    just do

    if (message == UI_OFF) {
    event_mask &= stuff;
    /* Back to poll() */

    and power management does the rest. If an event wakes up the process
    before we get to suspend in kernel we will wake it back up. If the event
    gets in after pm decides to idle via suspend then it'll bounce through
    the kernel back to a kernel resume, or potentially through a full
    hardware/software suspend/resume bounce. You have one person who needs to
    track the sequence - that's however is the guy sending UI_ON/UI_OFF
    information and making the screen light up.

    If you are dealing with a badly behaved app then you can't win because it
    may not have the magic 'suspend blockers' or will do it wrong. You
    can constrain it (brute force SIGSTOP after it refuses to UI_OFF for a
    bit, or via nice or other QoS policy) but you can't assume it'll
    magically managge itself. It is "badly behaved" so by that very
    definition you can't assume it has correct magic goo in it. (Side note:
    the extra magic goo and complexity of such blockers makes it more likely
    the app will be buggy and thus 'badly behaved' !)

    You can pick up which tasks are stopping the suspend fairly easily at the
    moment via the ktrace interfaces. Maybe there is a case for making that
    tidier but powertop and the like already demonstrate you can track this.

    A cpu policy can obviously expose offenders itself directly to user
    space. That (and indeed people not responding to UI_OFF) then lets your
    phone do

    X is misbehaving
    [Close it] [Allow this time] [Disable]

    and also to provide stats for each wakeup a policy manager can spot
    offenders (even those who are perhaps hard to see because they wake up a
    little bit every so often but just enough to mess up pm). In the x86
    world Arjan found a *lot* of that sort of stuff.

    Your policy manager can also act on it. The current policy manager is
    to fix app bugs and shows people up at conferences. I would imagine a
    google policy would be to collate misbehaving app reports at
    and use them both to assist in 'educating' authors and in scoring app
    store stuff.

    As it is <boop> X is misbehaving is a powerful economic lever in a
    pretty dynamic and functioning software market.

    Google seem to be pretty good at statistical data, I can't believe
    battery advice for apps on the app stores and indeed a 'where did my
    battery go' pie chart are beyond their wit, or beyond the end user to
    figure out.

    There are a considerable number of people shipping power constrained
    Linux devices without suddenely desperately needing extra magic potions.
    Are they really all just that much smarter than Google ?


     \ /
      Last update: 2010-05-27 23:21    [W:0.023 / U:115.812 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site