Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Fri, 28 May 2010, Alan Cox wrote:

> > Since I think we've now rejected the feature, do we have a clear picture about
> > what the Android people should do _instead_ and yet keep the battery life they
> > want?  Because I don't think telling "let them do what they want, who cares"
> > is right.
> 
> Today "idle" means "no task running"
> 
> If you are prepared to rephrase that as "no task that matters is running"
> what would need to answer ?
> 
> - How do we define who matters: QoS ?

Here are the deficiencies in the current PM-QOS implementation which 
would need to be solved for Android's purposes:

	The system includes parameters for latency and throughput.
	It does not include a parameter to describe whether timers
	are enabled.  The presumption is that timers are always
	enabled.

For example, the low-power state used by Android would be described as
one in which the CPU does not run and timers are disabled, with some
appropriate latencies and zero throughput.  On some platforms even some
interrupt sources are disabled (those not marked as wakeup-enabled).

	There's no way to indicate minimum system operating 
	requirements.

For example, we may know that work needs to be done without knowing 
specifically which processes are going to carry out that work.  In such 
cases we would like to require that the CPU continues to run at a 
certain minimum speed so long as _any_ threads are runnable, even if 
those threads don't have any QOS requirements of their own.

Similarly, the requirement that timers be enabled is a system-wide sort 
of thing, not necessarily applying to a particular thread (and in fact, 
not all timers are associated with a thread anyway).

	There's no way to boost the minimum system operating
	requirements upon the arrival of an event.

For example, when an input event enters the queue, it should be
possible to prevent the system from entering its lowest power state
until the event can be consumed by userspace.  Simply boosting the QOS
requirements of the threads waiting on the input queue isn't good
enough, because there may not be any such threads when the event occurs 
(they may be busy doing something else).

The matter of _which_ events should boost the system operating
requirements is debatable.  In the Android proposal it is a fixed set:
those events which enable a suspend blocker.  In theory it could
instead be determined by requests from userspace, although I don't know
how such requests would be expressed.


Until these weaknesses are rectified, Android cannot use the PM-QOS 
system or idle-time power management to satisfy its needs.  That's why 
they have to resort to forced suspends.

Can the PM-QOS framework be enhanced to include these considerations?  
I don't see why not (but on the other hand, I know nothing about its
internal workings).

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/