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, Aug 12, 2010 at 02:11:22PM +0300, Felipe Contreras wrote:
> On Thu, Aug 12, 2010 at 1:47 PM, Theodore Tso <tytso@mit.edu> wrote:
> > One thing I'm not clear on --- what's your goal?   Is your goal to keep suspend-blockers out of the kernel?   Is it to try to convince the android team suspend-blockers are a bad idea and to change Android to not use them?  Is it to push some other agenda?  Is it to discourage the Android team from trying to waste more time trying to get suspend-blockers (or equivalent functionality) from being added into the kernel?
>
> 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.

The question is not whether suspend blockers are a silver bullet (in my
opinion there are no silver bullets), but rather whether or not suspend
blockers are useful.

> So far, nobody has refuted these:
> 1) opportunistic suspend needs a good behaved user-space to work properly

As does dynamic power management.

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

> 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. (Or perhaps you are instead
saying that the implementation of the suspend-blocker infrastructure
itself is not straightforward? It is not clear from your words.)

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

This one I agree with.

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

Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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