> No, many suspend blockers protect data, not tasks. We block suspend
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
--
