From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Garrett Subject: Re: [PATCH 0/8] Suspend block api (version 6) Date: Fri, 14 May 2010 21:32:02 +0100 Message-ID: <20100514203202.GA12409@srcf.ucam.org> References: <1272667021-21312-1-git-send-email-arve@android.com> <87wrvl5479.fsf@deeprootsystems.com> <20100503215028.GB18910@srcf.ucam.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-pm-bounces@lists.linux-foundation.org Errors-To: linux-pm-bounces@lists.linux-foundation.org To: Paul Walmsley Cc: Greg Kroah-Hartman , Jesse Barnes , linux-kernel@vger.kernel.org, linux-pm@lists.linux-foundation.org, Liam Girdwood , Len Brown , Jacob Pan , Oleg Nesterov , linux-omap@vger.kernel.org, Linus Walleij , Daniel Walker , Theodore Ts'o , Brian Swetland , Mark Brown , Geoff Smith , Tejun Heo , Andrew Morton , Wu Fengguang , Arjan van de Ven List-Id: linux-omap@vger.kernel.org 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. Otherwise the immeasurably most likely outcome is that this code gets merged and we get to live with it. -- Matthew Garrett | mjg59@srcf.ucam.org