On Thu, May 27, 2010 at 06:45:25PM +0200, Thomas Gleixner wrote: > On Thu, 27 May 2010, Matthew Garrett wrote: > > No. Suspend blockers are designed to ensure that suspend isn't racy with > > respect to wakeup events. The bit that mitigates badly written > > applications is the bit where the scheduler doesn't run any more. > > > > If you're happy with a single badly written application being able to > > cripple your power management story, you don't need opportunistic > > suspend. But you still have complications when it comes to deciding to > > enter suspend at the same time as you receive a wakeup event. > > Wrong. Setting the QoS requirements of the badly written app to any > latency will allow the kernel to suspend even if the crappy app is > active. That's not what I want if I'm using the app at the time... > And again. I'm opposing the general chant that fixing crappy > applications in the kernel is a good thing. It's the worst decision we > could make. You still need the in-kernel suspend blockers if you want to guarantee that you can't lose wakeup events. But yes, if you're not concerned handling badly behaved applications then I believe that you can lose opportunistic suspend and just use the scheduler. > The whole notion of treating suspend to RAM any different than a plain > idle C-State is wrong. It's not different at all. You just use a > different mechanism which has longer takedown and wakeup latencies and > requires to shut down stuff and setup extra wakeup sources. My question was about explicit suspend states, not implicitly handling an identical state based on scheduler constraints. Suspend-as-a-C-state isn't usable on x86 - you have to explicitly trigger it based on some policy. And if you want to be able to do that without risking the loss of wakeup events then you need in-kernel suspend blockers. > I'm starting to get really grumpy about the chant that suspend > blockers are the only way to fix missed wakeups. That might be the > only way you can think of with your pink android glasses on, but again > this is not rocket science even if it does not fit into the current > way the kernel handles the whole suspend mechanism. I don't work for Google. I'm not an Android developer. > So if we really sit back and look at suspend as another idle state, > then we have first off the same requirements for entering it as we > have for any other idle state: There are various platforms where we cannot treat suspend as an idle state. Any solution that requires that doesn't actually solve the problem. Yes, this is *trivial* if you can depend on the scheduler. But we can't, and so it's difficult. -- Matthew Garrett | mjg59@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
