lkml.org 
[lkml]   [2010]   [Aug]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: Attempted summary of suspend-blockers LKML thread, take three
From
On Thu, Aug 12, 2010 at 8:43 PM, Paul E. McKenney
<paulmck@linux.vnet.ibm.com> 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 && alarm.sh'.

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 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 21:37    [from the cache]
©2003-2011 Jasper Spaans