From mboxrd@z Thu Jan 1 00:00:00 1970 From: Florian Mickler Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8) Date: Mon, 31 May 2010 22:12:19 +0200 Message-ID: <20100531221219.212bf119@schatten.dmk.lab> References: <20100527222514.0a1710bf@lxorguk.ukuu.org.uk> <20100527230806.4deb6de3@lxorguk.ukuu.org.uk> <20100527220949.GB10602@srcf.ucam.org> <20100527232357.6d14fdb2@lxorguk.ukuu.org.uk> <20100527223605.GB11364@srcf.ucam.org> <20100527235546.09f3ce8a@lxorguk.ukuu.org.uk> <20100528043114.GC26177@thunk.org> <1275030704.32462.11.camel@laptop> <1275120618.27810.12699.camel@twins> <1275149418.4503.128.camel@mulgrave.site> <1275156734.1645.496.camel@laptop> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1275156734.1645.496.camel@laptop> Sender: linux-kernel-owner@vger.kernel.org To: Peter Zijlstra Cc: James Bottomley , Arve =?ISO-8859-15?Q?Hj=F8n?= =?ISO-8859-15?Q?nev=E5g?= , tytso@mit.edu, LKML , Linux PM , Thomas Gleixner , Linux OMAP Mailing List , felipe.balbi@nokia.com, Alan Cox List-Id: linux-omap@vger.kernel.org On Sat, 29 May 2010 20:12:14 +0200 Peter Zijlstra wrote: > On Sat, 2010-05-29 at 11:10 -0500, James Bottomley wrote: > > > Correct, I strongly oppose using suspend. Not running runnable tasks is > > > not a sane solution. > > > > Look, this is getting into the realms of a pointless semantic quibble. > > The problem is that untrusted tasks need to be forcibly suspended when > > they have no legitimate work to do and the user hasn't authorised them > > to continue even if the scheduler sees them as runnable. Whether that's > > achieved by suspending the entire system or forcibly idling the tasks > > (using blocking states or freezers or something) so the scheduler can > > suspend from idle is something to be discussed, > > So what happens if you task is CPU bound and gets suspended and is > holding a resource (lock, whatever) that is required by someone else > that didn't get suspended? > > That's the classic inversion problem, and is caused by not running > runnable tasks. The trick with the approach currently discussed (i.e. opportunistic suspend, if you missed it): We suspend the whole machine. And I really think, this is the only way to do it. It is a big hammer, shure. But if you can pull it of... > > > but the net result is > > that we have to stop a certain set of tasks in such a way that they can > > still receive certain external events ... semantically, this is > > equivalent to not running runnable tasks in my book. > > Why would be care about external events? Clearly these apps are ill > behaved, otherwise they would have listened to the environment telling > them to idle. > > Why would you try to let buggy apps work as intended instead of break > them as hard as possible? Such policy promotes crappy code since people > get away with it. If I have a simple shell script then I don't wanna jump through hoops just to please your fragile kernel. And before you judge code that does not behave to work with YOUR buggy kernel, i would think twice. This cuts both ways. Just because the problem is too hard for you, this does not excuse forcing crappy kernels on other people. I think you have a point in that it is _in general_ not easily possible to solve. But for this case this is clearly a simple, to the point and working solution for android based phones. "Der Wurm muss dem Fisch schmecken, nicht dem Angler." > > > (Perhaps this whole > > thing is because the word runnable means different things ... I'm > > thinking a task that would consume power ... are you thinking in the > > scheduler R state?) > > Clearly I mean TASK_RUNNABLE, if not that the scheduler doesn't care. > > > Realistically, the main thing we need to do is stop timers posted > > against the task (which is likely polling in a main loop, that being the > > usual form of easy to write but power crazy app behaviour) from waking > > the task and bringing the system out of suspend (whether from idle or > > forced). > > Sure, that same main loop will probably receive a message along the > lines of, 'hey, screen is off, we ought to go sleep'. If after that it > doesn't listen, and more serious messages don't get responded to, simply > kill the thing. I think this would be a possibility. And maybe even sane. But I also think this has nothing to do with suspend_blockers. They block suspend. You know? > > Again, there is no reason what so ever to tolerate broken apps, it only > promotes crappy apps. > This simple doesn't solve the problem. Cheers, Flo