Re: [PATCH v2 16/35] preempt,rcu: warn on PREEMPT_RCU=n, preempt=full

[Paul E. McKenney]

On Mon, Jun 17, 2024 at 08:54:49AM -0700, Paul E. McKenney wrote:
> On Thu, Jun 06, 2024 at 06:38:57AM -0700, Paul E. McKenney wrote:
> > On Thu, Jun 06, 2024 at 01:53:25PM +0200, Peter Zijlstra wrote:
> > > On Thu, May 30, 2024 at 04:20:26PM -0700, Paul E. McKenney wrote:
> > > 
> > > > My selfish motivation here is to avoid testing this combination unless
> > > > and until someone actually has a good use for it.
> > > 
> > > That doesn't make sense, the whole LAZY thing is fundamentally identical
> > > to FULL, except it sometimes delays the preemption a wee bit. But all
> > > the preemption scenarios from FULL are possible.
> > 
> > As noted earlier in this thread, this is not the case for non-preemptible
> > RCU, which disables preemption across its read-side critical sections.
> > In addition, from a performance/throughput viewpoint, it is not just
> > the possibility of preemption that matters, but also the probability.
> > 
> > > As such, it makes far more sense to only test FULL.
> > 
> > You have considerable work left to do in order to convince me of this one.
> 
> On the other hand, it does make sense to select Tiny SRCU for all !SMP
> kernels, whether preemptible or not.

Except that testing made a liar out of me.  SRCU priority boosting would
be required.  So this one is also strictly for pre-testing lazy
preemption.

As usual, it seemed like a good idea at the time...  ;-)

							Thanx, Paul

>                                       And it also makes sense to test
> (but not *only* test and definitely *not* support) non-preemptible
> RCU running in a preemptible kernel, perhaps as a one-off, perhaps
> longer term.  The point being of course that the increased preemption
> rate of a fully preemptible kernel should uncover bugs that might appear
> in lazy-preemptible kernels only very rarely.
> 
> This might have been what you were getting at, and if so, apologies!
> But in my defense, you did say "only test FULL" above.  ;-)
> 
> 							Thanx, Paul