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.
On Wed, Jun 2, 2010 at 9:24 PM, Paul Mundt <[email protected]> wrote:
>
> 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.
That's definitely something we'd be interested in looking at. Some
upcoming ARM v7 architecture SMP SoCs we're seeing will support full
independent clock scaling and power gating for the individual cores --
if there's not enough work to keep the 2nd (or nth) cpu busy, there
would be good power savings to be had shutting it down.
I haven't poked around too much with how things work in SMP
environments -- are there per-cpu idle threads?
Brian
On Wed, 2010-06-02 at 23:58 -0700, Brian Swetland wrote:
>
> I haven't poked around too much with how things work in SMP
> environments -- are there per-cpu idle threads?
Yes, and we recently grew the infrastructure for asymmetric MP in the
processing capacity sense.