Re: [PATCH tip/core/rcu 4/7] rcu: Unify boost and kthread priorities

["Paul E. McKenney" <paulmck@linux.vnet.ibm.com>]

On Fri, Oct 31, 2014 at 05:51:43PM +0100, Peter Zijlstra wrote:
> 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.

OK, something like that might work in this case, at least making the
dubious assumption that I actually understand what you are getting at.  ;-)

You might be amused to hear that one of the solutions in my back pocket
for the potential problem of callbacks piling up in the current RCU
priority boosting scheme is to temporarily increase the priority.  This is
similar to how blimit gets increased if too many callbacks pile up.

Thus far, no need for this back-pocket solution, but I wanted to put it
out there in case it sparks something in the SCHED_DEADLINE approach.

							Thanx, Paul