lkml.org 
[lkml]   [2010]   [May]   [31]   [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 Sat, 29 May 2010 20:12:14 +0200
    Peter Zijlstra <peterz@infradead.org> wrote:

    > 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.

    The trick with the approach currently discussed (i.e.
    opportunistic suspend, if you missed it): We suspend the whole machine.

    And I really think, this is the only way to do it. It is a big hammer,
    shure. But if you can pull it of...

    >
    > > 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.

    If I have a simple shell script then I don't wanna jump through
    hoops just to please your fragile kernel.

    And before you judge code that does not behave to work with YOUR buggy
    kernel, i would think twice. This cuts both ways. Just because the
    problem is too hard for you, this does not excuse forcing crappy
    kernels on other people.

    I think you have a point in that it is _in general_ not easily
    possible to solve. But for this case this is clearly a simple, to the
    point and working solution for android based phones.

    "Der Wurm muss dem Fisch schmecken, nicht dem Angler."

    >
    > > (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.

    I think this would be a possibility. And maybe even sane. But I also
    think this has nothing to do with suspend_blockers. They block
    suspend. You know?

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

    This simple doesn't solve the problem.

    Cheers,
    Flo


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