Messages in this thread | | | Date | Fri, 31 Oct 2014 17:51:43 +0100 | From | Peter Zijlstra <> | Subject | Re: [PATCH tip/core/rcu 4/7] rcu: Unify boost and kthread priorities |
| |
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.
| |