From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Rafael J. Wysocki" Subject: Re: [PATCH 0/8] Suspend block api (version 6) Date: Sat, 15 May 2010 21:47:22 +0200 Message-ID: <201005152147.22122.rjw@sisk.pl> References: <1272667021-21312-1-git-send-email-arve@android.com> <87aas2azc5.fsf@deeprootsystems.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: 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: Arve =?iso-8859-1?q?Hj=F8nnev=E5g?= Cc: Greg Kroah-Hartman , Jesse Barnes , linux-kernel@vger.kernel.org, linux-pm@lists.linux-foundation.org, Arjan van de Ven , Matthew Garrett , Len Brown , Jacob Pan , Oleg Nesterov , Liam Girdwood , linux-omap@vger.kernel.org, Linus Walleij , Daniel Walker , Theodore Ts'o , Brian Swetland , Mark Brown , Geoff Smith , Tejun Heo , Andrew Morton , Wu Fengguang List-Id: linux-pm@vger.kernel.org On Saturday 15 May 2010, Arve Hj=F8nnev=E5g wrote: > On Fri, May 14, 2010 at 3:32 PM, Kevin Hilman > wrote: > > Matthew Garrett 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 specific= ally > >>> system power management-related, nor top-down, /sys/power/state-suspe= nd > >>> 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 ot= her > >>> 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. > > > = > No, apps need permission to block suspend. Are you referring to the fact the permissions of the special device file or something different? Rafael