Re: [PATCH v2 7/9] sched: define TIF_ALLOW_RESCHED

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

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@kernel.org> 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