[PATCH 0/8] Suspend block api (version 8)
in [Kernel]
|
Prev: [ANN] Linux Security Summit 2010 - Announcement and CFP
Next: [PATCH 4/8] PM: suspend_block: Add debugfs file
From: Peter Zijlstra on 31 May 2010 12:40 On Sat, 2010-05-29 at 11:10 -0500, James Bottomley wrote: > > If current hardware can't cope, too friggin bad, get better hardware. > > > > But the truth is, all your OMAP phones really can deal with it. > > That's rubbish and you know it. We do software workarounds for hardware > problems all the time ... try doing a git grep -i errata in arch x86, or > imagine a USB subsystem that only supported sane standards conforming > devices: that would have an almost zero intersect with the current USB > device market. > > The job of the kernel is to accommodate hardware as best it can ... > sometimes it might not be able to, but most of the time it does a pretty > good job. Sure, and if x86 could wake from S3 on a keypress/mouse movement etc.. you could use S3 as idle state.. not sure people would love the wakeup-latency, but that's a QoS matter. But if there simply are no suitable wakeup sources from an idle state (S3 really is nothing more than a hardware idle state) then it might not be suitable for transparent idle modes and no amount of software hackery will solve that. So what I'm saying is, if your hardware can't generate the needed wakeup events, the auto-suspend stuff won't work either. If it can it can be implemented as a regular idle mode. > The facts are that C states and S states are different and are entered > differently. For some omap hardware, the power consumption in the > lowest C state (with all the ancillary power control) is the same as S3, > that's fine, suspend from idle works as well as suspend to ram modulo > bad apps. For quite a lot of MSM hardware, the lowest C state power > consumption is quite a bit above S3. Wth is MSM? But really, why can't existing hardware get shipped with existing hacks, and for future hardware that does behave we have a proper solution? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Peter Zijlstra on 31 May 2010 12:40 On Sat, 2010-05-29 at 11:10 -0500, James Bottomley wrote: > > Not using suspend is exactly the point. As Alan has argued, propagating > > suspend blockers up into all regions of userspace will take much longer > > than fixing the hardware. > > Strange, that's not what I heard as the possible solution. <20100527232043.784d5c72(a)lxorguk.ukuu.org.uk> <20100528101755.7b5f6b8a(a)lxorguk.ukuu.org.uk> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Florian Mickler on 31 May 2010 16:20 On Sat, 29 May 2010 20:12:14 +0200 Peter Zijlstra <peterz(a)infradead.org> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Florian Mickler on 31 May 2010 16:50 On Mon, 31 May 2010 22:12:19 +0200 Florian Mickler <florian(a)mickler.org> wrote: > On Sat, 29 May 2010 20:12:14 +0200 > Peter Zijlstra <peterz(a)infradead.org> wrote: > > > > 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. Also why should that code on one device kill my uptime and on the other machine (my wall-plugged desktop) work just well? That doesn't sound right. Clearly opportunistic suspend is a workaround for battery-driven devices and no general solution. But it is not specific to android. At least not inherently. It could be useful for any embedded or mobile device where you can clearly distinguish important functions from convenience functions. I really can't understand the whole _fundamental_ opposition to this design choice. Cheers, Flo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: James Bottomley on 31 May 2010 17:00
On Sat, 2010-05-29 at 20:12 +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. OK ... but if the options are running and S3 for the entire platform, then all tasks get suspended and this isn't a problem. This is why the current wakelock implementation on the android platform works flawlessly today. Inversion only becomes a problem if tasks get individually idled, so you can see that, from the android point of view, we're creating a problem which their implementation doesn't have. In this view, S3 suspend does look elegant: it solves the inversion problem by suspending everything, it controls rogue applications' power consumption and it gets certain hardware into a lower power state than is possible from suspend from idle. The inelegance of the S3 suspend solution is the requirement to use these suspend blockers through kernel and user space to get the whole thing up again to respond to an event, which is an inelegance suspend from idle doesn't have. > > 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. That's not a correct characterisation. Badly behaved apps from a power point of view can do useful things for the user. The object is to contain the badness while still getting useful stuff done. > 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. > > > (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. > > Again, there is no reason what so ever to tolerate broken apps, it only > promotes crappy apps. Actually, no, if this were a correct view, we wouldn't have the huge x86 hardware work around problem because we'd just be able to tell manufacturers of shoddy or badly standards compliant stuff where to stick it. The great strength of the x86 commodity platform revolution was the fact that the hardware became cheap, plentiful and outside the ambit of a single walled garden manufacturer. It's great weakness is integration problems and shoddy hardware. We tolerate the weakness because the strength vastly outweighs it: and toleration to us in the kernel means driver work arounds ... it also means that if a device doesn't work with the kernel, we get blamed (rather than the manufacturer). By the same token, the revolution in smart phones is driven in quite a large part by the provision of third party applications. This commodity app view is almost the direct software analogue of the commodity platform view that has been so successful in hardware; Therefore, fair play seems to demand that we don't draw a hard line for software applications that we wouldn't draw for hardware devices. James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |