resume latency QoS support, unify suspend/resume into idle states

[Ingo Molnar <mingo@elte.hu>]

* Arve Hj?nnev?g <arve@android.com> wrote:

> On Thu, May 27, 2010 at 3:23 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > On Thu, 27 May 2010 23:09:49 +0100
> > Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> >
> >> On Thu, May 27, 2010 at 11:08:06PM +0100, Alan Cox wrote:
> >>
> >> > This is I believe robust (and has been implemented on some non x86
> >> > boxes). It depends on not forcing running tasks into suspend. That is the
> >> > key.
> >>
> >> We've already established that ACPI systems require us to force running
> >> tasks into suspend. How do we avoid the race in that situation?
> >
> > Android phones do not have ACPI. Embedded platforms do not have ACPI. MID 
> > x86 devices do not have ACPI.
> 
> Android does not only run on phones. It is possible that no android devices 
> have ACPI, but I don't know that for a fact. What I do know is that people 
> want to run Android on x86 hardware and supporting suspend could be very 
> benficial.

(If there's a sane framework then we'll fix x86 to fit into it and will deal 
with quirks.)

> > I would imagine the existing laptops will handle power management limited 
> > by the functionality they have available. Just like any other piece of 
> > hardware.
> 
> I think existing laptops (and desktops) can benefit from opportunistic 
> suspend support. If opportunistic suspend is used for auto-sleep after 
> inactivity instead of forced suspend, the user space suspend blocker api 
> will allow an application to delay this auto sleep until for instance a 
> download completes. This part could also be done with a user-space IPC call, 
> but having a standard kernel interface for it may make it more common. A 
> less common case, but more critical, is RTC alarms. I know my desktops can 
> wakeup at a specific time by programming an RTC alarm, but without suspend 
> blockers how do you ensure that the system does not suspend right after the 
> alarm triggered? I have a system that wakes up at specific times requested 
> by my DVR application, but I cannot use this system for anything else unless 
> I manually turn off the DVR application's auto-sleep feature. With suspend 
> blockers and something like the android alarm driver, I could use this 
> system for more than one application that have scheduled tasks and it would 
> be more usable for interactive applications.

I really like the level of detail and care that went into suspend-blockers, 
and i think the Android solution is very mature in terms of functionality 
offered to users.

In terms of bringing this depth of functionality and control to the upstream 
kernel, what do you think about Alan's QoS scheme, described in:

   <20100528001514.28e593ef@lxorguk.ukuu.org.uk>

?

It's in essence suspend-blockers on steroids. It consists of two main 
components:

 - Unify the 'suspended' state into the regular chain of idle states, and
   create a single, coherent and transparent way we handle system idleness.

 - Give apps a QoS attribute that allows them to express how long they can
   afford to wait for a wakeup. (A downloading app would set it to say 50msecs,
   and thus the kernel would know it automatically which method of idleness is 
   still achievable. If all currently running apps have a max(QoS) attribute 
   of infinite, then the kernel can suspend for an unlimited amount of time.)

AFAICS, and i have read through your suspend-blocker usecases, this should 
handle all the usecases you listed - and some more. (please yell if that's not 
so)

Suspend-blockers are equivalent to: 'app sets idle QoS latency to 0 msecs'.

(And on x86, for BIOS/CPU combos that allow it we can implement this scheme 
too.)

Thoughts?

	Ingo