> 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. How does having applications taking blockers fix that - it makes it worse. They are now blocking the kernel doing the right job. > If you're happy with a single badly written application being able to > cripple your power management story, you don't need opportunistic And taking a suspend blocker isn't "crippling your power management" ??? > What /is/ the correct way to solve this problem when entering explicit > suspend states? How do you guarantee that an event has been delivered to > userspace before transitioning into suspend? Now, this is a less > interesting problem if you're not using opportunistic suspend, but it's > still a problem. The same way as we deal with low power states on other non PC devices ? > That's no good. If the input device has been deactivated, how does the > wakeup event get delivered to the application? If the input device is letting itself get de-activated in a way that can lose events the input device driver is buggy. It's nobody elses business how it does the its job, and certainly *not* the applications. That's a kernel internal issue. You know the resource constraint exists because the driver knows it is open Your QoS guarantees tell you what you desired latency of response at the point you can become ready is. That's all your need to do it right. In kernel yes your device driver probably does need to say things like 'Don't go below C6 for a moment' just as a high speed serial port might want to say 'Nothing over 10mS please' I can't speak for Thomas, but I'm certainly not arguing that you don't need something that looks more like the blocker side of the logic *in kernel*, because there is stuff that you want to express which isn't tied to the task. So you need Userspace -> QoS guarantee expression, implied resource expression via device use. *NO* knowledge of device or platform in the application Kernel space Drivers -> Explicit guarantee expression not bound to tasks. Driver encapsulates the variety in the device hardware and expresses it in a uniform manner to the idling/suspend logic CPU Freq -> Encapsulates the variety in the CPU and core power functionality of devices, makes policy based upon the uniform express from the drivers and tasks All the autonomy is now in the right places, and we have requisite variety to actually manage the situation. Alan -- 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
