[lkml]   [2010]   [May]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 0/8] Suspend block api (version 6)
On Mon, May 03, 2010 at 09:40:26AM -0700, Kevin Hilman wrote:

> In my view, the truly significant difference between suspend blockers
> and runtime PM is what happens to userspace. So far, to me the only
> compelling argument for suspend blockers is the goal of forcibly
> shutting down userspace and thus forcing the system into idle
> (although drivers could still reject a suspend request.)

I'd say that this is certainly the main issue, though the remaining
periodic timers in the kernel are also inconvenient.

> And if untrusted userspace apps remain as the major problem, maybe we
> should aim for a solution directly targetting that problem. I'm just
> shooting from the hip now, but maybe containing (cgroups?) untrusted
> processes together into a set that could be frozen/idled so that runtime PM
> would be more effective would be a workable solution?

I considered this. The problem is that not all of your wakeup events
pass through trusted code. Assume we've used a freezer cgroup and the
applications are now frozen. One of them is blocking on a network
socket. A packet arrives and triggers a wakeup of the hardware. How do
we unfreeze the userspace app?

I agree that the runtime scenario is a far more appealing one from an
aesthetic standpoint, but so far we don't have a very compelling
argument for dealing with the starting and stopping of userspace. The
use-cases that Google have provided are valid and they have an
implementation that addresses them, and while we're unable to provide an
alternative that provides the same level of functionality I think we're
in a poor position to prevent this from going in.

Matthew Garrett |

 \ /
  Last update: 2010-05-03 23:53    [W:0.393 / U:0.724 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site