Message-ID: <77036c18-472a-46d5-a2b8-faec33770cd1@paulmck-laptop>
Date: Tue, 22 Oct 2024 16:49:00 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Ankur Arora <ankur.a.arora@...cle.com>
Cc: Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>, linux-kernel@...r.kernel.org,
	tglx@...utronix.de, mingo@...nel.org, juri.lelli@...hat.com,
	vincent.guittot@...aro.org, dietmar.eggemann@....com,
	rostedt@...dmis.org, bsegall@...gle.com, mgorman@...e.de,
	vschneid@...hat.com, frederic@...nel.org, efault@....de
Subject: Re: [PATCH 2/7] rcu: limit PREEMPT_RCU configurations

On Mon, Oct 21, 2024 at 12:20:58PM -0700, Ankur Arora wrote:
> 
> Paul E. McKenney <paulmck@...nel.org> writes:
> 
> > On Mon, Oct 21, 2024 at 01:27:55PM +0200, Sebastian Andrzej Siewior wrote:
> >> On 2024-10-18 10:38:15 [-0700], Paul E. McKenney wrote:
> >> > > > > I don't think this is always the case because the "preemptible" users
> >> > > > > would also get this and this is an unexpected change for them.
> >> > > >
> >> > > > Is this series now removing PREEMPT_NONE and PREEMPT_VOLUNTARY?
> >> > > no, not yet. It is only adding PREEMPT_LAZY as new model, next to
> >> > > PREEMPT_NONE and PREEMPT_VOLUNTARY. But is is likely to be on schedule.
> >> > >
> >> > > > As conceived last time around, the change would affect only kernels
> >> > > > built with one of the other of those two Kconfig options, which will
> >> > > > not be users expecting preemption.
> >> > >
> >> > > If you continue to use PREEMPT_NONE/ PREEMPT_VOLUNTARY nothing changes
> >> > > right now.
> >> >
> >> > Good, thank you!
> >> >
> >> > Presumably PREEMPT_NONE=y && PREEMPT_LAZY=y enables lazy preemption,
> >> > but retains non-preemptible RCU.
> >>
> >> PREEMPT_NONE=y && PREEMPT_LAZY=y is exclusive. Either NONE or LAZY.
> >
> > Ah, I was thinking in terms of the previous lazy-preemption patch series,
> > and just now got around to looking at the new one.  Apologies for my
> > confusion!
> 
> Minor point, but you might be thinking of PREEMPT_AUTO=y && PREEMPT_LAZY=y.

Entirely possible.

> >> > > > If PREEMPT_NONE and PREEMPT_VOLUNTARY are still around, it would be
> >> > > > far better to make PREEMPT_RCU depend on neither of those being set.
> >> > > > That would leave the RCU Kconfig settings fully automatic, and this
> >> > > > automation is not to be abandoned lightly.
> >> > >
> >> > > Yes, that was my intention - only to make is selectable with
> >> > > LAZY-preemption enabled but without dynamic.
> >> > > So you are not complete against it.
> >> >
> >> > Help me out here.  In what situation is it beneficial to make PREEMPT_RCU
> >> > visible, given that PREEMPT_NONE, PREEMPT_VOLUNTARY, PREEMPT, and
> >> > PREEMPT_FULL already take care of this automatically?
> >>
> >> 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.  ;-)
> >
> >> 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
> 
> Indeed. This was the original intent behind Thomas's proposal of preempt
> lazy.

Whew!!!  That is my recollection as well.

> > 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?
> 
> Users who care about low latency already have perfectly good options:
> PREEMPT, PREEMPT_DYNAMIC and now PREEMPT_RT.
> 
> I don't see the point of elevating low latency needs in all preemption
> models -- even those which are meant to be througput oriented.

Agreed!

> >> 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:
> 
> I don't think laziest was ever meant to be a serious option.
> 
> Peter mentioned that he'll be dropping it:
>  https://lore.kernel.org/lkml/20241008144049.GF14587@noisy.programming.kicks-ass.net/

Well, if Peter is going to drop it, I won't be evaluating it!  ;-)

							Thanx, Paul

> Ankur
> 
> > - 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?
> >
> > 							Thanx, Paul
> 
> 
> --
> ankur

Powered by blists - more mailing lists