From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-1?Q?Arve_Hj=F8nnev=E5g?= Subject: Re: suspend blockers & Android integration Date: Sat, 5 Jun 2010 18:24:43 -0700 Message-ID: References: <20100603193045.GA7188@elte.hu> <20100603232302.GA16184@elte.hu> <1275644619.27810.39462.camel@twins> <201006050138.30859.rjw@sisk.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org 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 List-Id: linux-omap@vger.kernel.org 2010/6/5 Thomas Gleixner : > On Sat, 5 Jun 2010, Arve Hj=F8nnev=E5g 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 backgroun= d >> >> > before allowing the machine to suspend. >> >> > >> >> >> >> It is not unrelated if the trusted app has stopped working but st= ill >> >> 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 runni= ng a >> > sane background task is going to save you power vs. an approach wh= ere >> > running a sane background task allows crap to consume power unconf= ined >> > until it is done. >> > >> If the task that is blocking suspend is using the cpu anyway, then t= he >> 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. --=20 Arve Hj=F8nnev=E5g