[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: Thomas Gleixner on 31 May 2010 17:00 On Sat, 29 May 2010, James Bottomley wrote: > 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. > > The facts are that C states and S states are different and are entered > differently. That's an x86'ism which is going away. And that's really completely irrelevant for the mobile device space. Can we please stop trying to fix todays x86 based laptop problems? They are simply not fixable. > 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. It's not acceptable to tell those > people "tough, your battery runs out in 30 minutes because you bought > the wrong hardware". We have to figure out how to get to S3 ... whether > this is from idle or some other mechanism is again a discussion point, > but not doing it is not an option. If you'd have read the answers from Alan carefully, then you'd have noticed that even x86 hardware is getting to the point where OMAP is today. i.e. support of transparent suspend from idle. If that wouldn't happen then x86 would be simply unusable for mobile devices. It's that easy. And we really do _NOT_ care about the existing laptop hardware which does not provide that because it's a lost case. Not only due to the missing (or just disabled) wakeup sources, also due to the fact that you cannot do sensible power management by completely disabling clock and/or power of unused devices in the chipset. There is a damn good reason why the mobile space is _NOT_ x86 based at the moment. Thanks, tglx -- 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 17:20 Hi, again! My two mails were probably a bit pointless and not helping to find a solution. There are notable and useful approaches mentioned by Peter to the mitigation problem. It's just that it's not the one and only way to think about this. Just rants, 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: Rafael J. Wysocki on 31 May 2010 17:20 On Saturday 29 May 2010, 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. That, among other things, is why suspend uses the freezer which guarantees that nothing like this will happen. > > 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. Yeah, and that's why Windows owns desktop market. ;-) > > (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. Do you realistically think that by hurting the _user_ you will make the _developer_ write better code? No, really. If the user likes the app very much (or depends on it or whatever makes him use it), he will rather switch the platform to one that allows him to run that app without _visible_ problems than complain to the developer, because _the_ _user_ _doesn't_ _realize_ that the app is broken. From the user's perspective, the platform that has problems with the app is broken, because the app apparently runs without problems on concurrent platforms. The whole "no reason to tolerate broken apps" midset is simply misguided IMO, because it's based on unrealistic assumptions. That's because in general users only need the platform for running apps they like (or need or whatever). If they can't run apps they like on a given platform, or it is too painful to them to run their apps on it, they will rather switch to another platform than stop using the apps. Thanks, Rafael -- 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:30 On Mon, 2010-05-31 at 22:49 +0200, Thomas Gleixner wrote: > On Sat, 29 May 2010, James Bottomley wrote: > > 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. > > > > The facts are that C states and S states are different and are entered > > differently. > > That's an x86'ism which is going away. And that's really completely > irrelevant for the mobile device space. Can we please stop trying to > fix todays x86 based laptop problems? They are simply not fixable. You're the one mentioning x86, not me. I already explained that some MSM hardware (the G1 for example) has lower power consumption in S3 (which I'm using as an ACPI shorthand for suspend to ram) than any suspend from idle C state. The fact that current x86 hardware has the same problem may be true, but it's not entirely relevant. > > 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. It's not acceptable to tell those > > people "tough, your battery runs out in 30 minutes because you bought > > the wrong hardware". We have to figure out how to get to S3 ... whether > > this is from idle or some other mechanism is again a discussion point, > > but not doing it is not an option. > > If you'd have read the answers from Alan carefully, then you'd have > noticed that even x86 hardware is getting to the point where OMAP is > today. i.e. support of transparent suspend from idle. If that wouldn't > happen then x86 would be simply unusable for mobile devices. It's that > easy. And we really do _NOT_ care about the existing laptop hardware > which does not provide that because it's a lost case. Not only due to > the missing (or just disabled) wakeup sources, also due to the fact > that you cannot do sensible power management by completely disabling > clock and/or power of unused devices in the chipset. There is a damn > good reason why the mobile space is _NOT_ x86 based at the moment. So not at all interested in x86 at the moment. For MSM hardware, it looks possible to unify the S and C states by doing suspend to ram from idle but I'm not sure how much work that is. 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/
From: Rafael J. Wysocki on 31 May 2010 17:40
On Monday 31 May 2010, Arve Hj�nnev�g wrote: > 2010/5/29 Alan Stern <stern(a)rowland.harvard.edu>: > > On Sat, 29 May 2010, Arve Hj�nnev�g wrote: > > > >> > In place of in-kernel suspend blockers, there will be a new type of QoS > >> > constraint -- call it QOS_EVENTUALLY. It's a very weak constraint, > >> > compatible with all cpuidle modes in which runnable threads are allowed > >> > to run (which is all of them), but not compatible with suspend. > >> > > >> This sound just like another API rename. It will work, but given that > >> suspend blockers was the name least objectionable last time around, > >> I'm not sure what this would solve. > > > > It's not just a rename. By changing this into a QoS constraint, we > > make it more generally useful. Instead of standing on its own, it > > becomes part of the PM-QOS framework. > > > > We cannot use the existing pm-qos framework. It is not safe to call > from atomic context. We've just merged a patch that fixed that if I'm not mistaken. Mark, did your PM QoS update fix that? > Also, it does not have any state constraints, so it iterates over every > registered constraint each time one of them changes. That's fixable IMO. > Nor does is currently provide any stats for debugging. That's why Alan is proposing to add that. > The original wakelock patchset supported a wakelock type so it could > be used to block more then suspend, but I had to remove this because > it "overlapped" with pm-qos. So, yes I do consider this just another > rename. It's an extension of an existing framework rather than an addition of a new one, with entirely new API and so on. Extending existing APIs is much preferred to adding new ones, in general. Rafael -- 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/ |