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: <201008071112.35790.rjw@sisk.pl>
Date:	Sat, 7 Aug 2010 11:12:35 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	"Ted Ts'o" <tytso@....edu>
Cc:	david@...g.hm, Brian Swetland <swetland@...gle.com>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	linux-pm@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
	arve@...roid.com, mjg59@...f.ucam.org, pavel@....cz,
	florian@...kler.org, stern@...land.harvard.edu,
	peterz@...radead.org, tglx@...utronix.de, alan@...rguk.ukuu.org.uk,
	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 Saturday, August 07, 2010, Rafael J. Wysocki wrote:
> On Saturday, August 07, 2010, Ted Ts'o wrote:
> > On Fri, Aug 06, 2010 at 08:14:09PM -0700, david@...g.hm wrote:
> > > 
> > > that description sounds far more like normal sleep power management
> > > that suspending. especially since they want to set timers to wake
> > > the system up and the defining characteristic of suspend (according
> > > to this thread) is that timers don't fire while suspended.
> > > 
> > > as I am seeing it, there are two reasons why this don't "just work"
> > > 
> > > 1. sleeping can't currently save as much power as suspending
> > 
> > No, I don't think that's the case at all.  The key thing here is that
> > *most* applications don't need to be modified to use suspend locks,
> > because even though they might be in an event loop, when the user user
> > turns off the display, the user generally doesn't want it doing things
> > on their behalf.
> > 
> > Again, take for example the Mac Book, since Apple has gotten this
> > right for most users' use cases.  When you close the lid, you even if
> > the application is under the misguided belief that it should be
> > checking every five seconds to see whether or not the web page has
> > reloaded --- actually, that's not what you want.  You probably want
> > the application to be forcibly put to sleep.  So the whole point of
> > the suspend blocker design is that you don't have to modify most
> > applications; they just simply get put to sleep when you close the
> > MacBook lid, or, in the case of the Android device, you push the
> > button that turns off the screen.
> 
> But in principle that need not mean suspending the entire system.
> To get applications out of the way, you need to freeze user space.
> However, that's not sufficient, because in addition to that you need to
> prevent deactivate the majority of interrupt sources to avoid waking up the
> CPU (from C-states) too often.

s/prevent deactivate/deactivate/

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