On Wed, Oct 18, 2023 at 01:41:07PM -0400, Steven Rostedt wrote:
> On Wed, 18 Oct 2023 10:19:53 -0700
> "Paul E. McKenney" <paulmck@xxxxxxxxxx> wrote:
> >
> > Isn't rcu_read_lock() defined as preempt_disable() and rcu_read_unlock()
> > as preempt_enable() in this approach? I certainly hope so, as RCU
> > priority boosting would be a most unwelcome addition to many datacenter
> > workloads.
> >
> > > With this approach the kernel is by definition fully preemptible, which
> > > means means rcu_read_lock() is preemptible too. That's pretty much the
> > > same situation as with PREEMPT_DYNAMIC.
> >
> > Please, just no!!!
>
> Note, when I first read Thomas's proposal, I figured that Paul would no
> longer get to brag that:
>
> "In CONFIG_PREEMPT_NONE, rcu_read_lock() and rcu_read_unlock() are simply
> nops!"
I will still be able to brag that in a fully non-preemptible environment,
rcu_read_lock() and rcu_read_unlock() are simply no-ops. It will
just be that the Linux kernel will no longer be such an environment.
For the moment, anyway, there is still userspace RCU along with a few
other instances of zero-cost RCU readers. ;-)
> But instead, they would be:
>
> static void rcu_read_lock(void)
> {
> preempt_disable();
> }
>
> static void rcu_read_unlock(void)
> {
> preempt_enable();
> }
>
> as it was mentioned that today's preempt_disable() is fast and not an issue
> like it was in older kernels.
And they are already defined as you show above in rcupdate.h, albeit
with leading underscores on the function names.
> That would mean that there will still be a "non preempt" version of RCU.
That would be very good!
> As the preempt version of RCU adds a lot more logic when scheduling out in
> an RCU critical section, that I can envision not all workloads would want
> around. Adding "preempt_disable()" is now low overhead, but adding the RCU
> logic to handle preemption isn't as lightweight as that.
>
> Not to mention the logic to boost those threads that were preempted and
> being starved for some time.
Exactly, thank you!
> > > > 6. You might think that RCU Tasks (as opposed to RCU Tasks Trace
> > > > or RCU Tasks Rude) would need those pesky cond_resched() calls
> > > > to stick around. The reason is that RCU Tasks readers are ended
> > > > only by voluntary context switches. This means that although a
> > > > preemptible infinite loop in the kernel won't inconvenience a
> > > > real-time task (nor an non-real-time task for all that long),
> > > > and won't delay grace periods for the other flavors of RCU,
> > > > it would indefinitely delay an RCU Tasks grace period.
> > > >
> > > > However, RCU Tasks grace periods seem to be finite in preemptible
> > > > kernels today, so they should remain finite in limited-preemptible
> > > > kernels tomorrow. Famous last words...
> > >
> > > That's an issue which you have today with preempt FULL, right? So if it
> > > turns out to be a problem then it's not a problem of the new model.
> >
> > Agreed, and hence my last three lines of text above. Plus the guy who
> > requested RCU Tasks said that it was OK for its grace periods to take
> > a long time, and I am holding Steven Rostedt to that. ;-)
>
> Matters what your definition of "long time" is ;-)
If RCU Tasks grace-period latency has been acceptable in preemptible
kernels (including all CONFIG_PREEMPT_DYNAMIC=y kernels), your definition
of "long" is sufficiently short. ;-)
Thanx, Paul
