linux-kernel - resume latency QoS support, unify suspend/resume into idle states

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]

Message-ID: <20100528092137.GD24058@elte.hu>
Date:	Fri, 28 May 2010 11:21:37 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Arve Hj?nnev?g <arve@...roid.com>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Alan Stern <stern@...land.harvard.edu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Florian Mickler <florian@...kler.org>, felipe.balbi@...ia.com,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	Linux PM <linux-pm@...ts.linux-foundation.org>
Subject: resume latency QoS support, unify suspend/resume into idle states


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

> On Thu, May 27, 2010 at 3:23 PM, Alan Cox <alan@...rguk.ukuu.org.uk> wrote:
> > On Thu, 27 May 2010 23:09:49 +0100
> > Matthew Garrett <mjg59@...f.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@...rguk.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
--
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/