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]

Date:	Mon, 2 Aug 2010 15:52:20 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	paulmck@...ux.vnet.ibm.com
Cc:	Arjan van de Ven <arjan@...radead.org>,
	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,
	swetland@...gle.com, peterz@...radead.org, tglx@...utronix.de,
	alan@...rguk.ukuu.org.uk
Subject: Re: Attempted summary of suspend-blockers LKML thread

On Monday, August 02, 2010, Paul E. McKenney wrote:
> On Sun, Aug 01, 2010 at 03:47:08PM -0700, Arjan van de Ven wrote:
> > On Sun, 1 Aug 2010 12:12:28 -0700
> > "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com> wrote:
...
> > Another one: freezing whole cgroups..... we have that today. it
> > actually works quite well.... of course the hard part is the decision
> > what to put in which cgroup, and at what frequency and duration you let
> > cgroups run.
> 
> Indeed, the Android guys seemed to be quite excited by cgroup freezing
> until they thought about the application-classification problem.
> Seems like it should be easy for some types of applications, but I do
> admit that apps can have non-trivial and non-obvious dependencies.

This isn't more difficult than deciding which applications will be allowed to
use wakelocks (in the wakelocks world).  It actually seems to be pretty much
equivalent to me. :-)

> > on the suspend blockers for drivers; the linux device runtime PM is
> > effectively doing the same things; it allows drivers to suspend/resume
> > individually (with a very nice API/programming model I should say) based
> > on usage. And it works on a tree level, so that it's relatively easy
> > to do things like "I want to go to <this magic deep idle state>, but
> > only if <this set of devices is suspended already>". This is obviously
> > an important functionality for all low power devices, ARM or x86. 
> > Suspend blockers had this functionality as part of what it did (they do
> > more obviously) but I'd wager that the current Linux infrastructure is
> > outright nicer. 
> 
> This is what Rafael has been working on?

If you mean the runtime PM framework, then yes, I've been working on it.

> Of course, the Android guys also want to pay attention to which apps
> are running as well as to the state of devices on the system.

In fact the runtime PM framework is also important to Android, because it
can be used in there, for example, to implement the "early suspend" thing
I referred to in one of my previous messages in this thread.

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