Matthew Garrett <mjg@xxxxxxxxxx> writes: > On Fri, May 14, 2010 at 02:20:43PM -0600, Paul Walmsley wrote: >> Hello, >> >> On Mon, 3 May 2010, Matthew Garrett wrote: >> >> > 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 problem of how to start and stop (some) userspace is not specifically >> system power management-related, nor top-down, /sys/power/state-suspend >> related. PM is just one potential user. >> >> It's hard to see how the Android opportunistic suspend approach would be >> useful for the other use-cases (e.g., checkpoint/restart). On the other >> hand, it's easier to see how something like freezer cgroups could be >> useful for system power management and checkpoint/restart. > > And difficult to see how to implement something using freezer cgroups > that actually works in this case. Look, I don't want to sound like I > have a one-track mind or anything, but all of these arguments would be > significantly more compelling if someone would actually provide a > concrete implementation proposal that deals with the set of use-cases > that Google's implementation does and which doesn't make anyone cry. That might be possible if this "set of use-cases" was available someplace. At least I haven't seen it, and would expect it to be in the docs included with patch 1. Another likely reason that that there hasn't been an alternate proposal (at least from some of us that are raising concerns) is because we already have a working solution to dynamic, system-wide PM that is 1) already in mainline and 2) shipping on consumer devices with very strict power budgets (as already pointed out in detail by Paul[2].) Yes, "excruciatingly bad" apps can kill PM on these systems since anyone can write apps, but the same is true on an opporunistic-suspend based system since any app could hold a suspend blocker whenever it wants. Kevin [1] https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025415.html [2] https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025532.html _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
