On Fri, Oct 31, 2014 at 09:42:30AM -0700, Paul E. McKenney wrote: > Well, you are supposed to determine the highest RT priority at which > your workload might run CPU-bound tasks, and set the boost priority > at some level above that. My model of RCU priority boosting is that > it should be used to make inadvertent high-priority infinite loops > easier to debug, but others might have different approaches.
Ah, so DL will never be CPU-bound -- and RR/FIFO _should_ never be, but I digress ;-) > > We should be able to detect the case where more and work piles on and > > the actual running does not appear to catch up, but I'm not sure what to > > do about it, seeing how system stability is at risk. > > I could imagine having a backup SCHED_FIFO task that handled the > case where callbacks were piling up, but synchronizing it with the > SCHED_DEADLINE task while avoiding callback misordering could be a bit > "interesting". (Recall that callback misordering messes up rcu_barrier().) Ah, so there is talk of 'soft' CBS modes, which instead of hard throttle either reclaim 'unused' DL bandwidth, or continue running in lower scheduling classes. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
