Date:	Thu, 12 Aug 2010 15:28:01 +0300
From:	Felipe Contreras <felipe.contreras@...il.com>
To:	Alan Stern <stern@...land.harvard.edu>
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, Aug 12, 2010 at 2:40 PM, Alan Stern <stern@...land.harvard.edu> wrote:
> 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:

[...]

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

Yes, but all user-space needs to be considered. There certainly will
be cases when people think a certain package doesn't need them, but it
turns out they did. Firefox? Nah... oh, wait a second, I want my
downloads to finish. Do you think there will be any linux desktop
distro willing to attempt that?

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

Certainly not, but it means when measuring against plain dynamic PM,
opportunistic suspend is less attractive.

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

Yes, and Nokia/Intel people believe they are close on their platforms.

Surely, at some point Android will reach that point too.

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

Android people have been selling the idea that suspend blockers are
not only for Android, but other platforms can benefit from them too. I
am arguing in that context. Hopefully you agree that that claim is
dubious at best.

Now, switching to Android... I'm sure if Android guys say their
user-space is far from the dynamic PM sweet-spot, then that's the
case. Surely, at some point they will reach it, so that they can
minimize power usage even when the device is actively used (it has
been explained that opportunistic suspend is not activated when screen
is on), maybe it will take one year, maybe two. Will they keep
opportunistic suspend around for those marginal gains? Maybe.

The question is why are we adding a user-space API that:
 1) no user-space beside Android has expresses interest in implementing
 2) is dubious whether the benefits are worth the pain for non-Android
user-space
 3) will become less and less attractive as dynamic PM gets closer to
the sweet-spot, and then surpass it
 4) Android can keep in a separate tree until it's clear in the linux
community that it's useful (if it ever happens)

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

Powered by blists - more mailing lists