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

Zygo Blaxell
2010-05-28T19:51:58Z

On Fri, May 28, 2010 at 08:16:20PM +0200, Peter Zijlstra wrote:
> On Fri, 2010-05-28 at 13:27 -0400, Zygo Blaxell wrote:
> > From my reading of this thread, there's a lot of overlap between
> > suspendblockers and constraints. Many use cases are served equally
> > well with one or the other,

Oops, I apparently meant "many use cases *of suspendblockers* are served
equally well with one or the other."

> If using suspend-blockers,
> Please explain to me how:
> - I will avoid the cpu going into some idle state for which the wakeup
> latency is larger than my RT app fancies?

...though I'd think you could do that by holding a suspendblocker, thus
preventing the CPU from going into any idle state at all.

There's four likely outcomes, corresponding to inclusion or non-inclusion
of suspend blockers and PM constraints in the kernel. Both could coexist
in the same kernel, since a suspend blocker can be trivially expressed as
"an extreme PM constraint with other non-constraint-related semantics."

It's the "other non-constraint-related semantics" that seem to be the
contentious issue. What can a suspend blocker do that a PM resource
constraint cannot do? If that set contains at least one useful use case,
then we need either suspend blockers, or some other thing that provides
for the use case.

Lots of people want PM constraints, and I haven't seen anyone suggest
there should *not* be PM constraints in the kernel some day. I've seen
a few "working and useful PM constraints aren't going to happen any time
soon" statements, and several "there's lots of stuff you still can't do
with PM constraints or suspend blockers" statements, but those aren't
arguments *against* PM constraints or *for* suspend blockers.