[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)
    On Thu, May 27, 2010 at 12:39:43AM +0100, Alan Cox wrote:

    > - Supporting Android needs well good
    > - Opportunistic suspend good
    > - Manner in which interface is expressed to userspace bad
    > - Latency constraint interface would be better
    > - Your existing behaviour can be implemented by a simplistic use of a
    > latency constraint interface
    > - We can fix a pile of other directly connected things at the same time
    > - Implementation internals I care far less about because we can fix those
    > later
    > - Suspend is just a power state
    > How does that fit your model and vision ?

    I don't entirely see how this works. In order to deal with poorly
    written applications, it's necessary to (optionally, based on some
    policy) ignore them when it comes to the scheduler. The problem is how
    to implement the optional nature of this in a race-free manner. This is
    obviously a pathological case, but imagine an application that does
    something along the following lines:

    int input = open ("/dev/input", O_RDONLY|O_NONBLOCK);
    char foo;

    while (1) {
    if (read(input, &foo, 1) > 0) {
    (do something)
    } else {
    (draw bouncing cows and clouds and tractor beams briefly)

    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
    one way which indicates to the scheduler that tasks in TASK_RUNNING
    should be scheduled, and when the session is idle we set the flag the
    other way and all processes in that cgroup get shifted to
    TASK_INTERRUPTIBLE or something.

    Except that doesn't work. If the session goes idle in the middle of the
    app drawing a frame, we'll stop the process and the task will never call
    read(). So the user hits a key, we wake up, nothing shifts from
    TASK_INTERRUPTIBLE into TASK_RUNNING, the key never gets read, we go
    back to sleep. The event never gets delivered.

    Now let's try this in the Android world. The user hits a key and the
    system wakes up. The input layer takes a suspend block. The application
    now draws all the cows it wants to, takes its own suspend block and
    reads the input device. This empties the queue and the kernel-level
    suspend block is released. The application then processes the event
    before releasing the suspend block. The event has been delivered and

    You can't express that with resource limits or QoS constraints. If you
    want to deal with this kind of situation then, as far as I can tell, you
    need either suspend blockers or something so close to them that it makes
    no difference.

    Matthew Garrett |

     \ /
      Last update: 2010-05-27 16:09    [W:0.043 / U:32.144 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site