[lkml]   [2010]   [Aug]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Attempted summary of suspend-blockers LKML thread, take three
    On Thu, Aug 12, 2010 at 8:43 PM, Paul E. McKenney
    <> wrote:
    > On Thu, Aug 12, 2010 at 02:11:22PM +0300, Felipe Contreras wrote:
    >> So far, nobody has refuted these:
    >>  1) opportunistic suspend needs a good behaved user-space to work properly
    > As does dynamic power management.

    Thus remains unrefuted.

    >>  2) if suspend blockers are enabled in a system, *all* user-space must
    >> implement them to work correctly
    > Really?  From what I can see, only PM-driving applications need to use
    > suspend blockers.

    "PM-driving applications" is a new invention, so how do you know if an
    application belongs to this category or not? Some application might be
    non-PM-driving most of the time, but suddenly become PM-driving. Well,
    you have to analyze *all* of them.

    Think about this... is bash a PM driving application? No, but what if
    you run: 'sleep 3600 &&'.

    Perhaps I should rewrite that as:
    2) if suspend blockers are enabled in the system; *all* user-space is affected

    >>  3) implementing suspend blockers in user-space is not a straight-forward task
    > Fortunately, experience thus far has shown that only a small fraction of
    > applications need to use suspend blockers.

    Wrong. We don't have any experience on that at all on typical linux
    ecosystems (remember that Android's user-space is very special).

    >> 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.
    > The length of this thread (and the ones preceding it) is mostly due to
    > people talking past each other.

    Perhaps half of the thread, or even one quarter of the thread can be
    attributed to that, but still the rest I think it's because people
    keep pushing in, and people keep pushing out.

    > For example, the Android folks seem to
    > believe that it is important that relatively unskilled people be able
    > to write simple apps, and that the system nevertheless be able to run
    > these apps in a relatively energy efficient manner.  Your proposals do
    > not address this issue.  This might be because you are not aware of
    > this desire, because you are not aware of the computing history that
    > argues in favor of this requirement, or because you simply don't like
    > this requirement.  Whatever the reason, until you face this requirement
    > head on, either addressing it or proving that it need not be addressed,
    > you will continue to be talking past the Android folks.

    This "requirement" is specific to Android's user-space, isn't it?

    Not Ubuntu, not Fedora, not MeeGo, not anyone with a typical
    user-space seems to be having this problem. I can argue to you that
    this problem can be solved in easier ways, but instead I will argue
    that perhaps we should wait for somebody besides Android to complain
    about it before providing a "solution". Because after all, what good
    is a "solution" provided by the kernel, if the user-space is not going
    to use it, ever.

    Felipe Contreras
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2010-08-12 21:37    [W:0.024 / U:1.472 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site