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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Sat, 5 Jun 2010 01:38:30 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Ingo Molnar <mingo@...e.hu>, tytso@....edu,
	Brian Swetland <swetland@...gle.com>,
	Neil Brown <neilb@...e.de>,
	"Arve Hj?nnev?g" <arve@...roid.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	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 Friday 04 June 2010, Peter Zijlstra wrote:
> On Fri, 2010-06-04 at 01:23 +0200, Ingo Molnar wrote:
> > Btw., i'd like to summarize the scheduler based suspend scheme proposed by
> > Thomas Gleixner, Peter Zijlstra and myself. I found no good summary of it in
> > the big thread, and there are also new elements of the proposal:
> 
> Just to clarify, my proposition doesn't go much further than treating
> 'suspend' as a genuine idle state (on suitable hardware, which x86 isn't).
> 
> > - Create a 'deep idle' mode that suspends. This, if all constraints
> >    are met, is triggered by the scheduler automatically: just like the other
> >    idle modes are triggered currently. This approach fixes the wakeup
> >    races because an incoming wakeup event will set need_resched() and
> >    abort the suspend.
> >
> 
> Right, so 'suspend' as idle seems (at least on UP/arm) a very sensible
> idea.  On SMP current suspend hot-unplugs all but the boot cpu, I'm not
> sure we need to do that, since if the system is genuinely idle, what races
> are there?
> 
> And if its not idle...
> 
> >   ( This mode can even use the existing suspend code to bring stuff down,
> >      therefore it also solves the pending timer problem and works even on
> >      PC style x86. )
> 
> You cannot solve the pending timer issue from idle, unless you allow idle
> to stop clock_monotonic, which would change idle semantics, and that is not
> something I can say is a good idea.
> 
> You want all idle states to have the same semantics, otherwise things just
> get way too confusing.
> 
> > - Solve crappy app confinement via the scheduler:
> >
> >    A first proposal was to use the existing cgroup mechanism,
> 
> I still believe containment is a cgroup problem.

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.

(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?

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/