Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Brian Swetland]

On Sat, May 29, 2010 at 7:10 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
>
> Here is an attempt to satisfy everyone as much as possible. ÂBut first
> an explicit disclaimer: When I say "suspend", I mean it as in
> "suspend-to-RAM"; i.e., a forced suspend and not a cpuidle mode.
>
> 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.
>
> The Android people want debugging and accountability. ÂSo in the most
> objectionable part of this proposal, we add a new way of registering
> QoS constraints: monitored constraints. ÂThe "monitored" implies that:
>
> Â Â Â ÂThe constraint has a name, which can be used for debugging
> Â Â Â Âand accounting;
>
> Â Â Â ÂThe kernel maintains statistics on the constraint's use and
> Â Â Â Âmakes them available to userspace; and

The name/statistics could obviously be gated by CONFIG_QOS_STATS or
the like -- we'd want such a thing in our world and others may want to
enable it to debug other situations, but the default could easily
remain "no overhead".

>
> Â Â Â ÂThe PM core is notified whenever the number of active monitored
> Â Â Â Âconstraints drops to 0.
>
> There is no /sys/power/policy file. ÂIn place of opportunistic suspend,
> we have "QoS-based suspend". ÂThis is initiated by userspace writing
> "qos" to /sys/power/state, and it is very much like suspend-to-RAM.
> However a QoS-based suspend fails immediately if there are any active
> normal QoS constraints incompatible with system suspend, in other
> words, any constraints requiring a throughput > 0 or an interrupt
> latency shorter than the time required for a suspend-to-RAM/resume
> cycle.
>
> If no such constraints are active, the QoS-based suspend blocks in an
> interruptible wait until the number of active QOS_EVENTUALLY
> constraints drops to 0. ÂWhen that happens, it carries out a normal
> suspend-to-RAM -- except that it checks along the way to make sure that
> no new QoS constraints are activated while the suspend is in progress.
> If they are, the PM core backs out and fails the QoS-based suspend.
>
> Userspace suspend blockers don't exist at all, as far as the kernel is
> concerned. ÂIn their place, the Android runs a power-manager program
> that receives IPC requests from other processes when they need to
> prevent the system from suspending or allow it to suspend. ÂThe power
> manager's main loop looks like this:
>
> Â Â Â Âfor (;;) {
> Â Â Â Â Â Â Â Âwhile (any IPC requests remain)
> Â Â Â Â Â Â Â Â Â Â Â Âhandle them;
> Â Â Â Â Â Â Â Âif (any processes need to prevent suspend)
> Â Â Â Â Â Â Â Â Â Â Â Âsleep;
> Â Â Â Â Â Â Â Âelse
> Â Â Â Â Â Â Â Â Â Â Â Âwrite "qos" to /sys/power/state;
> Â Â Â Â}

The issue with this approach is that if userspace wants to suspend
while a driver is holding a QOS_EVENTUALLY constraint, it's basically
going to spin constantly writing "qos" and failing.

Could we have write(powerstate_fd, "qos",3) block until all
QOS_EVENTUALLY constraints are lifted or the system successfully
suspends and resumes or a signal arrives?

> The idea is that receipt of a new IPC request will cause a signal to be
> sent, interrupting the sleep or the "qos" write.

Alternatively (to ipc), we could have a driver provide the same
suspendblock style interface to userspace and maps it to qos
constraints.  If it's something we maintain out-of-tree, no worries.
The kernel side api is the bit that's the headache to maintain
multiple versions of drivers with and without, after all.

> There remains a question as to which kernel drivers should create
> monitored QOS_EVENTUALLY constraints. ÂPerhaps userspace could be
> allowed to specify this (I don't know how). ÂIn any case, this is a
> relatively minor point.
>
> The advantages of this scheme are that this does everything the Android
> people need, and it does it in a way that's entirely compatible with
> pure QoS/cpuidle-based power management. ÂIt even starts along the path
> of making suspend-to-RAM just another kind of dynamic power state.
>
> If people such as Peter still want to complain that using
> suspend-to-RAM in Android phones isn't a good way to do power
> management, that's okay -- it's the designers' decision to program
> their phones the way they want. ÂAt least the kernel can give them the
> ability to do so in a way that doesn't compromise everybody else.

I'm sure Arve will weigh in on this later, but from what I can see it
certainly seems like this model provides us with the functionality
we're looking for, provided the issue with
spinning-while-waiting-for-drivers-to-release-constraints is sorted
out.

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/