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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 9 Aug 2010 11:54:47 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	david@...g.hm
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>, "Ted Ts'o" <tytso@....edu>,
	Felipe Contreras <felipe.contreras@...il.com>,
	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 Mon, Aug 09, 2010 at 11:28:02AM -0700, david@...g.hm wrote:
> On Mon, 9 Aug 2010, Paul E. McKenney wrote:
> 
> >On Mon, Aug 09, 2010 at 11:24:53AM +0100, Alan Cox wrote:
> >
> >[ . . . ]
> >
> >>>would agree that in the ideal world, it would be nice if you could
> >>>have applications that make the correct performance/battery
> >>>utilization tradeoff for devices running on 800 mWh batteries, 94,000
> >>>mWh batteries, and while running on the AC mains.  But I don't believe
> >>>that it's likely to be true, and if you want to try to beat up on
> >>>application writers one at a time to be power optimized --- as far as
> >>>I'm concerned, that's an argument *for* suspend blockers, since I'm
> >>>not big believer in plans that begin, "First, you command the tides of
> >>>the sea to go back", King Canute style.  :-)
> >>
> >>Suspend blockers drive the system policy part way into the apps, that in
> >>turn makes the apps very vulnerable to change in their environment because
> >>you've specialised them. I am sure that in the Android world it's
> >>considered fine, and that the marketing and business people even like
> >>this binding together - but it doesn't generalise and will blow up in
> >>people's faces in the future.
> >>
> >>To consider your tide analogy - suspend blockers is like trying to
> >>program the waves individually. Show me a suspend blocker aware open
> >>office patch 8)
> >
> >But wouldn't an office suite run as a power-oblivious application on an
> >Android device?  After all, office applications do not need to run when
> >the screen is turned off, so these the applications do not need to use
> >suspend blockers.  That said, I could easily imagine that significant
> >work would be required to make OpenOffice run on Android, not due to
> >suspend blockers, but rather due to Android's unusual user space.
> 
> pick your application if you don't like the example.

I like the office-suite example just fine.

> but also, which android system should the applicaton be written for?
> the phone with a 800maH battery or a larger device with a 94,000maH
> battery?

Does battery size make a difference in this particular case?

> well bahaved applications (not doing unnecessary wakeups, etc) are
> well bahaved, no matter what system they are on

Yep.  Your point being what exactly?  That all applications should be
required to be power-optimized, and that any technology that automates
energy efficiency should be rejected out of hand?  If so, please justify
your position.

>                                                 (explicitly setting
> allowable timer fuzz is linux specific, but will again help on any
> system)

Setting aside the question of how timer fuzz will help on non-Linux
systems if timer fuzz is specific to Linux...

							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/