Re: [PATCH v3] rcu: Only boost rcu reader tasks with lower priority than boost kthreads

["Paul E. McKenney" <paulmck@kernel.org>]

On Wed, Mar 30, 2022 at 09:35:26PM +0200, Uladzislau Rezki wrote:
> > On Fri, Mar 18, 2022 at 05:50:35AM +0000, Zhang, Qiang1 wrote:
> > > On Sat, Mar 12, 2022 at 03:11:04AM +0000, Zhang, Qiang1 wrote:
> > > > On 2022-03-11 10:22:26 [+0800], Zqiang wrote:
> > > > > When RCU_BOOST is enabled, the boost kthreads will boosting readers
> > > > > who are blocking a given grace period, if the current reader tasks
> > > >                                        ^ Period.
> > > > 
> > > > > have a higher priority than boost kthreads(the boost kthreads priority
> > > > > not always 1, if the kthread_prio is set), 
> > > > 
> > > > >>This confuses me:
> > > > >>- Why does this matter
> > > > 
> > > > In preempt-rt system, if the kthread_prio is not set, it prio is 1.
> > > > the boost kthreads can preempt almost  rt task, It will affect
> > > > the real-time performance of some user rt  tasks.  In preempt-rt systems,
> > > > in most scenarios, this kthread_prio will be configured.
> > > >
> > > >Just following up...  These questions might have been answered, but
> > > >I am not seeing those answers right off-hand.
> > > >
> > > >Is the grace-period latency effect of choosing not to boost high-priority
> > > >tasks visible at the system level in any actual workload?
> > > >
> > > >Suppose that a SCHED_DEADLINE task has exhausted its time quantum,
> > > >and has thus been preempted within an RCU read-side critical section.
> > > >Can priority boosting from a SCHED_FIFO prio-1 task cause it to start
> > > >running?
> > > >
> > > >Do delays in RCU priority boosting cause excessive grace-period
> > > >latencies on real workloads, even when all the to-be-boosted
> > > >tasks are SCHED_OTHER?
> > > >
> > > >Thoughts?
> > > 
> > > I have tested this modification these days,  I originally planned to generate a Kconfig option to control
> > > whether to skip tasks with higher priority than boost kthreads. but it doesn't seem necessary
> > >  because I find it's optimization is not particularly
> > > obvious in the actual scene, I find that tasks with higher priority than boost kthreads 
> > > will quickly exit the rcu critical area , even if be preempted in the rcu critical area.
> > > sorry for the noise.
> > 
> > Thank you for getting back with this information, and no need to
> > apologize.  We all get excited about a potential change from time to time.
> > Part of us maintainers' jobs is to ask hard questions when that appears
> > to be happening.  ;-)
> > 
> > If you have continued interest in this area, it would be good to keep
> > looking.  After all, neither RCU expedited grace periods nor RCU priority
> > boosting were designed with these new use cases in mind, so it is quite
> > likely that there is a useful change to be made in there somewhere.
> > 
> > You see, RCU expedited grace periods were designed for throughput rather
> > than latency.  The original use case was an old networking API that
> > needed to wait for a grace period on each and every one of a series of
> > some tens of thousands of system calls.  If one or two of those system
> > calls took a few hundred milliseconds, but the rest completed in less than
> > a millisecond, no harm done.  (Yes, there are now newer APIs that allow
> > many changes to be made with only the one grace-period wait.  But the
> > kernel must continue to support the old API: Never Break Userspace.)
> > 
> > For its part, RCU priority boosting was originally designed for
> > debuggging.  The point was to avoid OOMing the system when someone
> > misconfigured their application's real-time priorities.  As you know,
> > such misconfiguration can easily prevent low-priority RCU readers from
> > ever completing.
> > 
> > So it is reasonably likely that some change or another is needed.  After
> > all, new use cases require new functionality and new fixes.  The trick
> > is figuring out which change makes sense amongst the huge group of other
> > possible changes that each add much more complexity than improvement.
> > But part of the process of finding that change that makes sense is trying
> > out quite a few changes that don't help all that much.  ;-)
> > 
> Sorry for the late response, but i think i should comment on it since i
> have tried to simulate and test this patch on Android device. Basically
> we do have RT tasks in Android and i do not see that the patch that is
> in question makes any difference. Actually i was not able to trigger its
> functionality at all.
> 
> >From the other hand, i have tried to simulate it making an RT environment
> with SCHED_FIFO tasks and some synchronize_rcu_expedited() users. Indeed
> i can trigger it but it is very specific env. and number of triggering or
> tasks bypassing(high prio) is almost zero.

Thank you both!

I will set this aside for the time being.  I am sure that further
adjustments will be needed, but time will tell.

							Thanx, Paul