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 | mjg59@xxxxxxxxxxxxx _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
