lkml.org 
[lkml]   [2010]   [Aug]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Attempted summary of suspend-blockers LKML thread, take three
    On Thu, 12 Aug 2010, Felipe Contreras wrote:

    > My goal is to shine light. I've heard many invalid arguments in favor
    > of suspend blockers, I want to shut them down.
    >
    > In my mind it's crystal clear that independently of what opportunistic
    > suspend is supposed to be fixing, the fact of the matter is that it's
    > not a silver bullet as it's claimed to be.
    >
    > So far, nobody has refuted these:
    > 1) opportunistic suspend needs a good behaved user-space to work properly

    That seems entirely reasonable, since opportunistic suspend is
    essentially a userspace facility. Its in-kernel component is extremely
    small (and is already in mainline).

    > 2) if suspend blockers are enabled in a system, *all* user-space must
    > implement them to work correctly

    That isn't clear at all. Certainly they must be implemented correctly
    in some parts of userspace. But other parts can simply be denied
    permission to use them.

    > 3) implementing suspend blockers in user-space is not a straight-forward task

    Perhaps so. Lots of things in userspace aren't straight-forward --
    GUIs, for example. So what? That's not a proof they shouldn't be
    used.

    > 4) there's a point where sleeping (not doing work) has diminished returns

    Agreed. It is platform dependent. The Google people seem to believe
    strongly they have not yet reached that point on their platforms.

    > So, as the length of this thread has shown, the benefits of
    > opportunistic suspend are *dubious* at best, and more likely not worth
    > the changes needed in user-space which eventually will get pretty
    > close to what suspend blockers can achieve even in ideal circumstances
    > by just doing dynamic PM.

    You're ignoring the fact that Android has _already_ made the necessary
    userspace changes. Now you're going to ask them to change back,
    offering as motivation the loss of a real (albeit "dubious")
    power-saving advantage? Why should they accept your offer?

    Alan Stern



    \
     
     \ /
      Last update: 2010-08-12 13:43    [W:4.152 / U:0.052 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site