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. _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
