> No, many suspend blockers protect data, not tasks. We block suspend > when there are unprocessed input events in the kernel queue. > User-space then blocks suspend before reading those events, and it > blocks suspend using a different suspend blocker when its queue of > processed events become not-empty. That sounds to me like higher level user space implementation plus a kernel driver imposing a power level limit. The fact your suspend blockers as a user construct are tied to data isn't neccessarily what the kernel needs to provide. That aside we could equally provide latency constraints using a file handle based semantic like your suspend blockers. That would make it easier to do suspend blockers in those terms and provide an interface that can be used for more elegant expression of desire. I suggested setpidle() to keep resources tied and bounded to tasks and to make SMP work nicely. I have no problem with the latency constraints being floating file handles, although some thought would be needed as to how that is then mapped to SMP. The problem with an arbitary mapping is that if I have an 8 processor system I might want to use the latency info to stuff tasks onto different cores so that most of them are in a deeper idle than the others. I can't do that unless I know who the latency constraint applies to. But hopefully someone in scheduler land has bright ideas - eg could we keep a per task variable and adjust it when people open/close blockers with the assumption being anyone who has open a given constraint is bound by it and nobody else is. Might need it to be a constraintfs so you can open other people's constraints but all the framework for that is there in the kernel too. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html