linux-kernel - Re: suspend blockers & Android integration

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]

Message-ID: <alpine.LFD.2.00.1006050148080.2933@localhost.localdomain>
Date:	Sat, 5 Jun 2010 02:05:30 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
cc:	Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...e.hu>,
	tytso@....edu, Brian Swetland <swetland@...gle.com>,
	Neil Brown <neilb@...e.de>, Arve Hj?nnev?g <arve@...roid.com>,
	Alan Stern <stern@...land.harvard.edu>,
	Felipe Balbi <felipe.balbi@...ia.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Florian Mickler <florian@...kler.org>,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	Linux PM <linux-pm@...ts.linux-foundation.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	James Bottomley <James.Bottomley@...e.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Kevin Hilman <khilman@...prootsystems.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: suspend blockers & Android integration

On Sat, 5 Jun 2010, Rafael J. Wysocki wrote:
> I kind of agree here, so I'd like to focus a bit on that.
> 
> Here's my idea in the very general terms:
> 
> (1) Use the cgroup freezer to "suspend" the "untrusted" apps (ie. the ones
>     that don't use suspend blockers aka wakelocks in the Android world) at the
>     point Android would normally start opportunistic suspend.

There is an additional benefit to this approach:

     In the current android world a background task (e.g. download
     initiated before the screensaver kicked in) prevents the suspend,
     but that also means that the crapplications can still suck power
     completely unconfined.

     With the cgroup freezer you can "suspend" them right away and
     just keep the trusted background task(s) alive which allows us to
     go into deeper idle states instead of letting the crapplications
     run unconfined until the download finished and the suspend
     blocker goes away.
 
> (2) Allow the cpuidle framework to put CPUs into low-power states after the
>     "trusted" apps (ie. the ones that use suspend blockers in the Android
>     world) have gone idle.
> 
> (3) Teach the cpuidle framework to schedule runtime suspend of I/O devices
>     before idling the last CPU (*).
> 
> (4) Design a mechanism to resume the I/O devices suspended in (3) so that
>     they are not powered up unnecessarily (that's going to be difficult as far
>     as I can see).
> 
> This way, in principle, we should be able to save (at least almost) as much
> energy as the opportunistic suspend currently used by Android, provided that
> things will be capable of staying idle for extended periods of time.
> 
> (*) That may require per-device PM QoS requirements to be used, in which case
>     devices may even be suspended earlier if the PM QoS requirements of all
>     of their users are met.
> 
> I wonder what people think.  Is this realistic and if so, would it be difficult
> to implement?

I think it's realistic and not overly complicated to implement.

Thanks,

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