[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)
    On Sat, 2010-05-29 at 20:12 +0200, Peter Zijlstra 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.

    OK ... but if the options are running and S3 for the entire platform,
    then all tasks get suspended and this isn't a problem. This is why the
    current wakelock implementation on the android platform works flawlessly

    Inversion only becomes a problem if tasks get individually idled, so you
    can see that, from the android point of view, we're creating a problem
    which their implementation doesn't have.

    In this view, S3 suspend does look elegant: it solves the inversion
    problem by suspending everything, it controls rogue applications' power
    consumption and it gets certain hardware into a lower power state than
    is possible from suspend from idle.

    The inelegance of the S3 suspend solution is the requirement to use
    these suspend blockers through kernel and user space to get the whole
    thing up again to respond to an event, which is an inelegance suspend
    from idle doesn't have.

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

    That's not a correct characterisation. Badly behaved apps from a power
    point of view can do useful things for the user. The object is to
    contain the badness while still getting useful stuff done.

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

    Actually, no, if this were a correct view, we wouldn't have the huge x86
    hardware work around problem because we'd just be able to tell
    manufacturers of shoddy or badly standards compliant stuff where to
    stick it.

    The great strength of the x86 commodity platform revolution was the fact
    that the hardware became cheap, plentiful and outside the ambit of a
    single walled garden manufacturer. It's great weakness is integration
    problems and shoddy hardware. We tolerate the weakness because the
    strength vastly outweighs it: and toleration to us in the kernel means
    driver work arounds ... it also means that if a device doesn't work with
    the kernel, we get blamed (rather than the manufacturer).

    By the same token, the revolution in smart phones is driven in quite a
    large part by the provision of third party applications. This commodity
    app view is almost the direct software analogue of the commodity
    platform view that has been so successful in hardware; Therefore, fair
    play seems to demand that we don't draw a hard line for software
    applications that we wouldn't draw for hardware devices.


     \ /
      Last update: 2010-05-31 22:55    [W:2.379 / U:0.936 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site