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

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

On 2024-10-21 09:48:03 [-0700], Paul E. McKenney wrote:
> > We have now NONE, VOLUNTARY, PREEMPT, PREEMPT_RT (as in choose one).
> > 
> > This series changes it to NONE, VOLUNTARY, PREEMPT, LAZY, LAZIEST.
> > Ignore LAZIEST. PREEMPT_RT is a on/ off bool.
> 
> In terms of preemptibility, isn't the order from least to most preemptible
> NONE, VOLUNTARY, LAZIEST, LAZY, PREEMPT, and PREEMPT_RT?  After all,
> PREEMPT will preempt more aggressively than will LAZY which in turn
> preempts more aggressively than LAZIEST.
> 
> And I finally do see the later patch in Peter's series that removes
> PREEMPT_RT from the choice.  Plus I need to look more at LAZIEST in
> order to work out whether Peter's suckage is our robustness.  ;-)

For LAZIEST PeterZ added "do we want this?". I haven't tested this but
since there is no forced preemption at all, it should be what is NONE
without cond_resched() & friends. So I don't know if it stays, I don't
think so.

> > Based on my understanding so far, you have nothing to worry about.
> > 
> > With NONE + VOLUNTARY removed in favor of LAZY or without the removal
> > (yet)  you ask yourself what happens to those using NONE, go to LAZY and
> > want to stay with !PREEMPT_RCU, right?
> > With LAZY and !PREEMPT_DYNAMIC there is still PREEMPT_RCU as of now.
> > And you say people using !PREEMPT_DYNAMIC + LAZY are the old NONE/
> > VOLUNTARY users and want !PREEMPT_RCU.
> 
> Yes.
> 
> > This could be true but it could also attract people from PREEMPT which
> > expect additional performance gain due to LAZY and the same "preemption"
> > level. Additionally if PREEMPT gets removed because LAZY turns out to be
> > superior then PREEMPT_DYNAMIC makes probably no sense since there is
> > nothing to switch from/ to.
> 
> We definitely have users that would migrate from NONE to LAZY.  Shouldn't
> their needs outweigh the possible future users that might (or might not)
> find that (1) LAZY might be preferable to PREEMPT for some users and
> (2) That those users would prefer that RCU be preemptible?

Yes. I have no idea which of those two (PREEMPT_RCU vs !PREEMPT_RCU) is
to be preferred. Therefore I'm suggesting to make configurable here.

If you have a benchmark for memory consumption or anything else of
interest, I could throw it a box or two to get some numbers. I've been
looking at free memory at boot and this was almost the same (+- noise).

> > Therefore I would suggest to make PREEMPT_RCU 
> > - selectable for LAZY && !PREEMPT_DYNAMIC, default yes
> > - selected for LAZY && PREEMPT_DYNAMIC
> > - the current unchanged state for NONE, VOLUNTARY, PREEMPT (with
> >   !PREEMPT_DYNAMIC)
> > 
> > Does this make sense to you?
> 
> Not really.  At the very least, default no.
> 
> Unless LAZIEST makes the most sense for us (which will take time to
> figure out), in which case make PREMPT_RCU:
> 
> - hard-defined =n for LAZIEST.
> - selectable for LAZY && !PREEMPT_DYNAMIC, default yes
> - selected for LAZY && PREEMPT_DYNAMIC
> - the current unchanged state for NONE, VOLUNTARY, PREEMPT (with
>   !PREEMPT_DYNAMIC)
> 
> Or am I still missing some aspect of this series?

no, that is perfect.

> 							Thanx, Paul

Sebastian