Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933923Ab0FFBYp (ORCPT ); Sat, 5 Jun 2010 21:24:45 -0400 Received: from mail-pv0-f174.google.com ([74.125.83.174]:42986 "EHLO mail-pv0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933768Ab0FFBYo convert rfc822-to-8bit (ORCPT ); Sat, 5 Jun 2010 21:24:44 -0400 MIME-Version: 1.0 In-Reply-To: References: <20100603193045.GA7188@elte.hu> <20100603232302.GA16184@elte.hu> <1275644619.27810.39462.camel@twins> <201006050138.30859.rjw@sisk.pl> Date: Sat, 5 Jun 2010 18:24:43 -0700 Message-ID: Subject: Re: suspend blockers & Android integration From: =?ISO-8859-1?Q?Arve_Hj=F8nnev=E5g?= To: Thomas Gleixner Cc: "Rafael J. Wysocki" , Peter Zijlstra , Ingo Molnar , tytso@mit.edu, Brian Swetland , Neil Brown , Alan Stern , Felipe Balbi , LKML , Florian Mickler , Linux OMAP Mailing List , Linux PM , Alan Cox , James Bottomley , Linus Torvalds , Kevin Hilman , "H. Peter Anvin" , Arjan van de Ven Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2569 Lines: 53 2010/6/5 Thomas Gleixner : > On Sat, 5 Jun 2010, Arve Hj?nnev?g wrote: >> 2010/6/5 Thomas Gleixner : >> >> > Well, that's simply an application bug which sucks battery with or >> >> > without suspend blockers. So it's unrelated to the freezing of >> >> > untrusted apps while a trusted app still works in the background >> >> > before allowing the machine to suspend. >> >> > >> >> >> >> It is not unrelated if the trusted app has stopped working but still >> >> blocks suspend. The battery drains when you combine them. >> > >> > What you are describing is a problem which is not solvable either way. >> > If you take the lock and do not release it you're not going to >> > suspend. I never claimed that any other mechanism resolves this. >> > >> Whether you claimed it or not, this is the only case where using >> cgroups would have a significant power saving over what we get with >> suspend. The trusted app is idle and the untrusted app is frozen, so >> we enter a low power mode from idle. > > Nothing else was what I said and depending on the usage pattern this > can be significant. Just you converted a perfectly sensible technical > argument into a quibble about BUGs in applicatins which are not > confinable by defintion. > >> > But this is not related to the fact that freezing crap while running a >> > sane background task is going to save you power vs. an approach where >> > running a sane background task allows crap to consume power unconfined >> > until it is done. >> > >> If the task that is blocking suspend is using the cpu anyway, then the >> bad app does not increase the power consumption nearly as much as if >> the task that blocked suspend is idle. > > That's utter bullshit. If the app missed to release the supsend > blocker then your crappy "while(1);" app is killing you in no time, > while the same frozen crappy "while(1);" does no harm at all. > This is the bug I described above. If the app that blocked suspend did not release the suspend blocker and went idle, then another while(1) app will drain the battery. If the app that blocked suspend only blocked suspend while it needs to run (which is the typical reason to block suspend) then the system is not idle anyway and the impact of the while(1) app is much less severe. -- Arve Hj?nnev?g -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/