linux-kernel - Re: [PATCH 2/7] rcu: limit PREEMPT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a71a7154-7cd4-44da-be41-5f2831fbfbbe@paulmck-laptop>
Date: Mon, 21 Oct 2024 09:48:03 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: 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

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!

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

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

							Thanx, Paul