Re: [PATCH 2/7] rcu: limit PREEMPT_RCU configurations

[Paul E. McKenney]

On Wed, Oct 09, 2024 at 10:52:18PM +0200, Peter Zijlstra wrote:
> On Wed, Oct 09, 2024 at 11:24:09AM -0700, Paul E. McKenney wrote:
> > On Wed, Oct 09, 2024 at 08:01:17PM +0200, Peter Zijlstra wrote:
> > > On Wed, Oct 09, 2024 at 09:54:06AM -0700, Ankur Arora wrote:
> > > > PREEMPT_LAZY can be enabled stand-alone or alongside PREEMPT_DYNAMIC
> > > > which allows for dynamic switching of preemption models.
> > > > 
> > > > The choice of preemptible RCU or not, however, is fixed at compile
> > > > time. Given the trade-offs made to have a preemptible RCU, some
> > > > configurations which have limited preemption might prefer the
> > > > stronger forward-progress guarantees of PREEMPT_RCU=n.
> > > > 
> > > > Accordingly, explicitly limit PREEMPT_RCU=y to PREEMPT_DYNAMIC,
> > > > PREEMPT, PREEMPT_RT.
> > > > 
> > > > This means that (PREEMPT_LAZY=y, PREEMPT_DYNAMIC=n), which selects
> > > > PREEMPTION will run with PREEMPT_RCU=n. The combination (PREEMPT_LAZY=y,
> > > > PREEMPT_DYNAMIC=y), will run with PREEMPT_RCU=y.
> > > 
> > > I am completely confused by this. Why do we want this?
> > 
> > In order to support systems that currently run CONFIG_PREEMPT=n that
> > are adequately but not overly endowed with memory.  If we allow all
> > RCU readers to be preempted, we increase grace-period latency, and also
> > increase OOM incidence.  Which we would like to avoid.
> > 
> > But we do want lazy preemption otherwise, for but one thing to reduce
> > tail latencies and to reduce the need for preemption points.  Thus, we
> > want a way to allow lazy preemption in general, but to continue with
> > non-preemptible RCU read-side critical sections.
> > 
> > Or am I once again missing your point?
> 
> Even without this patch this is allowed, right? It's just a default
> that's changed. If people want to run PREEMPT_RCU=n, they can select it.
> 
> I just don't see a point in making this change.

Because we don't need a bunch of people surprised by this change in
behavior.

							Thanx, Paul