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 for Android: free password hash cracker in your pocket

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

Message-ID: <20241021112755.m7dWNbc0@linutronix.de>
Date: Mon, 21 Oct 2024 13:27:55 +0200
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: "Paul E. McKenney" <paulmck@...nel.org>
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 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.

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

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.

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.

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?

> 							Thanx, Paul

Sebastian