On Thu, May 27, 2010 at 06:06:43PM +0200, Thomas Gleixner wrote: > On Thu, 27 May 2010, Alan Stern wrote: > > And to answer Thomas's question: The whole reason for having in-kernel > > suspend blockers is so that userspace can tell the system to suspend > > without losing wakeup events. > > > > Suppose a key is pressed just as a user program writes "mem" to > > /sys/power/state. The keyboard driver handles the keystroke and queues > > an input event. Then the system suspends and doesn't wake up until > > some other event occurs -- even though the keypress was an important > > one and it should have prevented the system from suspending. > > > > With in-kernel suspend blockers and opportunistic suspend, this > > scenario is prevented. That is their raison-d'etre. > > I tend to disagree. You are still looking at suspend as some extra > esoteric mechanism. We should stop doing this and look at suspend (to > RAM) as an additional deep idle state, which is well defined in terms > of power savings and wakeup latency. That's what I think opportunistic > suspend is all about. Now if you look at our current idle states in > x86 the incoming keystroke is never lost. > For systems with runtime PM and deep idle states in cpuidle suspend is already fairly opportunistic. If sleep states (including suspend to RAM and CPU off) are factored in to cpuidle then it's very easy to get in to situations where everything simply shuts off automatically, which can be problematic if a platform doesn't expose any external wakeup sources. Platforms still need to be able to establish some heuristics, whether this is via blocking certain state transitions or simply defining a maximum acceptable suspend depth irrespective of latency (at least we presently don't have a clean interface for preventing entry in to impossible to recover from idle states outside of latency hints via PM QoS, or at least not one that I'm aware of). On the other hand, while this isn't that difficult for the UP case it does pose more problems for the SMP case. Presently the suspend paths (suspend-to-RAM/hibernate/kexec jump) all deal with disabling and enabling of non-boot CPUs via CPU hotplug explicitly, which will clear them from the online CPU map. We would have to rework the semantics a bit if cpuidle were also permitted to opportunistically offline CPUs. -- 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
