Message-ID: <Pine.LNX.4.44L0.1005290941060.30763-100000@netrider.rowland.org>
Date:	Sat, 29 May 2010 10:10:07 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Florian Mickler <florian@...kler.org>
cc:	Peter Zijlstra <peterz@...radead.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linux PM <linux-pm@...ts.linux-foundation.org>,
	Arve Hjønnevåg <arve@...roid.com>,
	Brian Swetland <swetland@...gle.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>
Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

On Sat, 29 May 2010, Florian Mickler wrote:

> On Sat, 29 May 2010 12:42:37 +0200
> Peter Zijlstra <peterz@...radead.org> wrote:

> > Now, all I'm interested in is providing interfaces from the kernel where
> > needed, so that userspace can be optimally frugal with power usage, and
> > can monitor/contain badly behaving tasks.
> > 
> 
> I think this is a sensible approach.

Here is an attempt to satisfy everyone as much as possible.  But first 
an explicit disclaimer: When I say "suspend", I mean it as in 
"suspend-to-RAM"; i.e., a forced suspend and not a cpuidle mode.

In place of in-kernel suspend blockers, there will be a new type of QoS 
constraint -- call it QOS_EVENTUALLY.  It's a very weak constraint, 
compatible with all cpuidle modes in which runnable threads are allowed 
to run (which is all of them), but not compatible with suspend.

The Android people want debugging and accountability.  So in the most 
objectionable part of this proposal, we add a new way of registering 
QoS constraints: monitored constraints.  The "monitored" implies that:

	The constraint has a name, which can be used for debugging
	and accounting;

	The kernel maintains statistics on the constraint's use and
	makes them available to userspace; and

	The PM core is notified whenever the number of active monitored
	constraints drops to 0.

There is no /sys/power/policy file.  In place of opportunistic suspend,
we have "QoS-based suspend".  This is initiated by userspace writing
"qos" to /sys/power/state, and it is very much like suspend-to-RAM.
However a QoS-based suspend fails immediately if there are any active
normal QoS constraints incompatible with system suspend, in other
words, any constraints requiring a throughput > 0 or an interrupt
latency shorter than the time required for a suspend-to-RAM/resume
cycle.

If no such constraints are active, the QoS-based suspend blocks in an
interruptible wait until the number of active QOS_EVENTUALLY
constraints drops to 0.  When that happens, it carries out a normal
suspend-to-RAM -- except that it checks along the way to make sure that
no new QoS constraints are activated while the suspend is in progress.  
If they are, the PM core backs out and fails the QoS-based suspend.

Userspace suspend blockers don't exist at all, as far as the kernel is 
concerned.  In their place, the Android runs a power-manager program 
that receives IPC requests from other processes when they need to 
prevent the system from suspending or allow it to suspend.  The power 
manager's main loop looks like this:

	for (;;) {
		while (any IPC requests remain)
			handle them;
		if (any processes need to prevent suspend)
			sleep;
		else
			write "qos" to /sys/power/state;
	}

The idea is that receipt of a new IPC request will cause a signal to be 
sent, interrupting the sleep or the "qos" write.

There remains a question as to which kernel drivers should create 
monitored QOS_EVENTUALLY constraints.  Perhaps userspace could be 
allowed to specify this (I don't know how).  In any case, this is a 
relatively minor point.

The advantages of this scheme are that this does everything the Android
people need, and it does it in a way that's entirely compatible with 
pure QoS/cpuidle-based power management.  It even starts along the path
of making suspend-to-RAM just another kind of dynamic power state.

If people such as Peter still want to complain that using
suspend-to-RAM in Android phones isn't a good way to do power
management, that's okay -- it's the designers' decision to program
their phones the way they want.  At least the kernel can give them the
ability to do so in a way that doesn't compromise everybody else.

Alan Stern

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

Powered by blists - more mailing lists