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]

Message-ID: <Pine.LNX.4.44L0.1008120733130.21006-100000@netrider.rowland.org>
Date:	Thu, 12 Aug 2010 07:40:03 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Felipe Contreras <felipe.contreras@...il.com>
cc:	Theodore Tso <tytso@....edu>, <paulmck@...ux.vnet.ibm.com>,
	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>, <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, 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

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