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] [day] [month] [year] [list]

Message-ID: <20241023065808.ck-vPSbO@linutronix.de>
Date: Wed, 23 Oct 2024 08:58:08 +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-22 16:54:11 [-0700], Paul E. McKenney wrote:
> > 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.
> 
> As Ankur noted, the original intent was to move people from both
> PREEMPT_NONE and PREEMPT_VOLUNTARY to lazy preemption.  This strongly
> suggests setting the value of PREEMPT_RCU to n.  Not just the default,
> but the value.  We need to have a definite non-speculative case for
> forcing people to once again worry about RCU preemptibility, and I know
> of no such case.

okay.

> > 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).
> 
> Unfortunately, the benchmark is the fleet and all of the various
> non-public applications that run on it.  :-(

I see.

> > > > 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.
> 
> And assuming LAZIEST is not to be with us much longer, this becomes:
> 
> - hard-defined to "no" for LAZY && !PREEMPT_DYNAMIC, just like
>   NONE or VOLUNTARY with !PREEMPT_DYNAMIC.
> - selected for LAZY && PREEMPT_DYNAMIC
> - the current unchanged state for NONE, VOLUNTARY, PREEMPT (with
>   !PREEMPT_DYNAMIC)
> 
> Fair enough?

Guess this hard no and worry later makes sense.

> 							Thanx, Paul

Sebastian