linux-kernel - Re: Attempted summary of suspend-blockers LKML thread, take three

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 12 Aug 2010 22:34:47 +0300
From:	Felipe Contreras <felipe.contreras@...il.com>
To:	paulmck@...ux.vnet.ibm.com
Cc:	Theodore Tso <tytso@....edu>, Alan Cox <alan@...rguk.ukuu.org.uk>,
	david@...g.hm, Brian Swetland <swetland@...gle.com>,
	linux-pm@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
	arve@...roid.com, mjg59@...f.ucam.org, pavel@....cz,
	florian@...kler.org, rjw@...k.pl, stern@...land.harvard.edu,
	peterz@...radead.org, tglx@...utronix.de, menage@...gle.com,
	david-b@...bell.net, James.Bottomley@...e.de, arjan@...radead.org,
	swmike@....pp.se, galibert@...ox.com, dipankar@...ibm.com
Subject: Re: Attempted summary of suspend-blockers LKML thread, take three

On Thu, Aug 12, 2010 at 8:43 PM, Paul E. McKenney
<paulmck@...ux.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/