Re: [RFC PATCH 47/86] rcu: select PREEMPT_RCU if PREEMPT

[Paul E. McKenney]

On Tue, Nov 07, 2023 at 07:27:03PM -0500, Steven Rostedt wrote:
> On Tue,  7 Nov 2023 13:57:33 -0800
> Ankur Arora <ankur.a.arora@xxxxxxxxxx> wrote:
> 
> > With PREEMPTION being always-on, some configurations might prefer
> > the stronger forward-progress guarantees provided by PREEMPT_RCU=n
> > as compared to PREEMPT_RCU=y.
> > 
> > So, select PREEMPT_RCU=n for PREEMPT_VOLUNTARY and PREEMPT_NONE and
> > enabling PREEMPT_RCU=y for PREEMPT or PREEMPT_RT.
> > 
> > Note that the preemption model can be changed at runtime (modulo
> > configurations with ARCH_NO_PREEMPT), but the RCU configuration
> > is statically compiled.
> 
> I wonder if we should make this a separate patch, and allow PREEMPT_RCU=n
> when PREEMPT=y?

You mean independent of this series?  If so, I am not all that excited
about allowing a new option due to the effect on testing.  With this full
series, the number of test scenarios is preserved.

Actually, that is not exactly true, is it?  It would be if we instead had
something like this:

config PREEMPT_RCU
	bool
	default y if PREEMPT || PREEMPT_RT
	depends on !PREEMPT_NONE && !PREEMPT_VOLUNTARY
	select TREE_RCU

Any reason why this would be a problem?

Or to put it another way, do you know of anyone who really wants
a preemptible kernel (CONFIG_PREEMPT=y, CONFIG_PREEMPT_NONE=n
and CONFIG_PREEMPT_VOLUNTARY=n) but also non-preemptible RCU
(CONFIG_PREEMPT_RCU=y)?  If so, why?  I am having some difficulty seeing
how this combination could be at all helpful.  And if it is not helpful,
we should not allow people to shoot themselves in the foot with it.

> This could allow us to test this without this having to be part of this
> series.

OK, if you mean for testing purposes but not to go to mainline without
the rest of the series, I am good with that idea.

And thank you to Ankur for preserving non-preemptible RCU for those of us
using system that are adequately but not generously endowed with memory!

							Thanx, Paul