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

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: <20100801054816.GI2470@linux.vnet.ibm.com>
Date:	Sat, 31 Jul 2010 22:48:16 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	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,
	swetland@...gle.com, peterz@...radead.org, tglx@...utronix.de,
	alan@...rguk.ukuu.org.uk
Subject: Re: Attempted summary of suspend-blockers LKML thread

On Sat, Jul 31, 2010 at 09:52:14PM -0700, Arjan van de Ven wrote:
> On Sat, 31 Jul 2010 10:58:42 -0700
> "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com> wrote:
> 
> > o	"Power-aware application" are applications that are permitted
> > 	to acquire suspend blockers on Android.  Verion 8 of the
> > 	suspend-blocker patch seems to use group permissions to
> > determine which applications are classified as power aware.
> > 
> > 	More generally, power-aware applications seem to be those that
> > 	have permission to exert some control over the system's
> > 	power state.
> 
> I don't like the term "Power aware application". An application is well
> behaved or it isn't. "aware" has nothing to do with it.

Applications are often complex enough to be aware of some things, naive
about others, well behaved in some ways, and ill-behaved in others.
This has been the case for some decades now, so it should not come as
a surprise.

I am of course open to suggestions for alternatives to the term "power
aware application", but most definitely not to obfuscating the difference
between power awareness (or whatever name one wishes to call it) and
the overall quality of the application, whatever "quality" might mean
in a given context.

> > REQUIREMENTS
> > 
> > o	Reduce the system's power consumption in order to (1) extend
> > 	battery life and (2) preserve state until AC power can be
> > obtained.
> 
> AC power is not relevant in discussions around power: Applications MUST
> behave well, AC or DC both. Just ask any data center operator on how
> much they run on DC and if he cares about power consumption.
> Conversely, most mobile usages (both phone, tablet or netbook) are "DC
> only"....

Alan Stern suggested "external power" in place of "AC", which makes sense
to me.  His suggestion does have the virtue of rendering irrelevant the
difference between an AC adapter and a DC adapter for use in automobiles.

And in my experience, people working with mobile devices care -much- more
about energy efficiency than do data-center operators.

> > o	It is necessary to be able to use power-naive applications.
> > 	Many of these applications were designed for use in PC
> > platforms where power consumption has historically not been of great
> > 	concern, due to either (1) the availability of AC power or (2)
> > 	relatively undemanding laptop battery-lifetime expectations.
> > The system must be capable of running these power-naive applications
> > 	without requiring that these applications be modified, and
> > must be capable of reasonable power efficiency even when power-naive
> > 	applications are available.
> 
> I don't buy this argument as is.
> 
> I do buy that there are many sloppy applications; mostly written quickly
> for <appstore of the month>.  But most if not all of these are written
> for the device in question (at least that is true for Apple and Android)

Making an application power-aware or power-naive is a choice, similar to
the choice between making an application SMP-aware or single-threaded.
This sort of choice is completely orthogonal to ill-behavior, sloppiness,
or whatever the pejorative of the day might be.

The choice between power-aware and power-naive will depend on who is
available to do the programming and how valuable power-awareness is
for the application in question.  Given that people who program PC-class
applications are much more common than are people who program with
energy efficiency in mind, the power-naive choice will be attractive
in many cases.

Or do you have some other interpretation of what the Android guys are
looking for?

							Thanx, Paul
--
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/