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)
    > No. Suspend blockers are designed to ensure that suspend isn't racy with 
    > respect to wakeup events. The bit that mitigates badly written
    > applications is the bit where the scheduler doesn't run any more.

    How does having applications taking blockers fix that - it makes it
    worse. They are now blocking the kernel doing the right job.

    > If you're happy with a single badly written application being able to
    > cripple your power management story, you don't need opportunistic

    And taking a suspend blocker isn't "crippling your power management" ???

    > What /is/ the correct way to solve this problem when entering explicit
    > suspend states? How do you guarantee that an event has been delivered to
    > userspace before transitioning into suspend? Now, this is a less
    > interesting problem if you're not using opportunistic suspend, but it's
    > still a problem.

    The same way as we deal with low power states on other non PC devices ?

    > That's no good. If the input device has been deactivated, how does the
    > wakeup event get delivered to the application?

    If the input device is letting itself get de-activated in a way that can
    lose events the input device driver is buggy. It's nobody elses business
    how it does the its job, and certainly *not* the applications.

    That's a kernel internal issue.

    You know the resource constraint exists because the driver knows it is
    open
    Your QoS guarantees tell you what you desired latency of response at the
    point you can become ready is.

    That's all your need to do it right.

    In kernel yes your device driver probably does need to say things like
    'Don't go below C6 for a moment' just as a high speed serial port might
    want to say 'Nothing over 10mS please'

    I can't speak for Thomas, but I'm certainly not arguing that you don't
    need something that looks more like the blocker side of the logic *in
    kernel*, because there is stuff that you want to express which isn't tied
    to the task.

    So you need

    Userspace -> QoS guarantee expression, implied resource
    expression via device use. *NO* knowledge of
    device or platform in the application

    Kernel space

    Drivers -> Explicit guarantee expression not bound to
    tasks. Driver encapsulates the variety in the
    device hardware and expresses it in a uniform
    manner to the idling/suspend logic

    CPU Freq -> Encapsulates the variety in the CPU and core
    power functionality of devices, makes policy
    based upon the uniform express from the drivers
    and tasks

    All the autonomy is now in the right places, and we have requisite variety
    to actually manage the situation.

    Alan


    \
     
     \ /
      Last update: 2010-05-27 18:13    [W:0.040 / U:30.808 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site