lkml.org 
[lkml]   [2010]   [May]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
    From
    Date
    On Sat, 2010-05-29 at 11:10 -0500, James Bottomley wrote:
    > > Correct, I strongly oppose using suspend. Not running runnable tasks is
    > > not a sane solution.
    >
    > Look, this is getting into the realms of a pointless semantic quibble.
    > The problem is that untrusted tasks need to be forcibly suspended when
    > they have no legitimate work to do and the user hasn't authorised them
    > to continue even if the scheduler sees them as runnable. Whether that's
    > achieved by suspending the entire system or forcibly idling the tasks
    > (using blocking states or freezers or something) so the scheduler can
    > suspend from idle is something to be discussed,

    So what happens if you task is CPU bound and gets suspended and is
    holding a resource (lock, whatever) that is required by someone else
    that didn't get suspended?

    That's the classic inversion problem, and is caused by not running
    runnable tasks.

    > but the net result is
    > that we have to stop a certain set of tasks in such a way that they can
    > still receive certain external events ... semantically, this is
    > equivalent to not running runnable tasks in my book.

    Why would be care about external events? Clearly these apps are ill
    behaved, otherwise they would have listened to the environment telling
    them to idle.

    Why would you try to let buggy apps work as intended instead of break
    them as hard as possible? Such policy promotes crappy code since people
    get away with it.

    > (Perhaps this whole
    > thing is because the word runnable means different things ... I'm
    > thinking a task that would consume power ... are you thinking in the
    > scheduler R state?)

    Clearly I mean TASK_RUNNABLE, if not that the scheduler doesn't care.

    > Realistically, the main thing we need to do is stop timers posted
    > against the task (which is likely polling in a main loop, that being the
    > usual form of easy to write but power crazy app behaviour) from waking
    > the task and bringing the system out of suspend (whether from idle or
    > forced).

    Sure, that same main loop will probably receive a message along the
    lines of, 'hey, screen is off, we ought to go sleep'. If after that it
    doesn't listen, and more serious messages don't get responded to, simply
    kill the thing.

    Again, there is no reason what so ever to tolerate broken apps, it only
    promotes crappy apps.





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