Message-ID: <87ldyhi7ol.fsf@oracle.com>
Date: Mon, 21 Oct 2024 12:20:58 -0700
From: Ankur Arora <ankur.a.arora@...cle.com>
To: paulmck@...nel.org
Cc: Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Peter Zijlstra
 <peterz@...radead.org>,
        Ankur Arora <ankur.a.arora@...cle.com>, 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


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.

>> > > > 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.

> 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.

>> 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/

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