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 Thu, 27 May 2010 17:07:14 +0100
    Matthew Garrett <mjg59@srcf.ucam.org> wrote:

    > On Thu, May 27, 2010 at 04:05:43PM +0100, Alan Cox wrote:
    > > > Now, if the user is playing this game, you want it to be scheduled. If
    > > > the user has put down their phone and the screen lock has kicked in, you
    > > > don't want it to be scheduled. So we could imagine some sort of cgroup
    > > > that contains untrusted tasks - when the session is active we set a flag
    > >
    > > I would hope not, because I'd rather prefer my app that used the screen
    > > to get the chance to save important data on what it was doing
    > > irrespective of the screen blank: "I have an elegant proof for this
    > > problem but my battery has gone flat"
    >
    > Perhaps set after callbacks are made. But given that the approach
    > doesn't work anyway...

    Which approach doesn't work, and why ?

    > > What is the problem here - your device driver for the display can block
    > > tasks it doesn't want to use the display.
    >
    > It's still racy. Going back to my example without any of the suspend
    > blocking code, but using a network socket rather than an input device:
    >
    > int input = socket(AF_INET, SOCK_STREAM|SOCK_NONBLOCK, 0);
    > char foo;
    > struct sockaddr addr;
    > connect (input, &addr, sizeof(addr))
    > while (1) {
    > if (read(input, &foo, 1) > 0) {
    > (do something)
    > } else {
    > (draw bouncing cows and clouds and tractor beams briefly)
    > }
    > }
    >
    > A network packet arrives while we're drawing. Before we finish drawing,
    > the policy timeout expires and the screen turns off.

    Which is correct for a badly behaved application. You said you wanted to
    constrain it. You've done so. Now I am not sure why such a "timeout"
    would expire in the example as the task is clearly busy when drawing, or
    is talking to someone else who is in turn busy. Someone somewhere is
    actually drawing be it a driver or app code.

    For a well behaved application you are drawing so you are running
    drawing stuff so why would you suspend. The app has said it has a
    latency constraint that suspend cannot meet, or has a device open that
    cannot meet the constraints in suspend.

    You also have the socket open so you can meaningfully extract resource
    constraint information from that fact.

    See it's not the read() that matters, it's the connect and the close.

    If your policy for a well behaved application is 'thou shalt not
    suspend in a way that breaks its networking' then for a well behaving app
    once I connect the socket we cannot suspend that app until such point as
    the app closes the socket. At any other point we will break the
    connection. Whether that is desirable is a policy question and you get to
    pick how much you choose to trust an app and how you interpret the
    information in your cpufreq and suspend drivers.

    If you have wake-on-lan then the network stack might be smarter and
    choose to express itself as

    'the constraint is C6 unless the input queue is empty in which
    case suspend is ok as I have WoL and my network routing is such
    that I can prove that interface will be used'

    In truth I doubt much hardware can make such an inference but some phones
    probably can. On the other hand for /dev/input/foo you can make the
    inference very nicely thank you.

    Again wake on lan information does not belong in the application !





    \
     
     \ /
      Last update: 2010-05-27 18:37    [W:5.218 / U:0.036 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site