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: <88b90ca8-9d73-4691-b391-43891a057c77@paulmck-laptop>
Date: Tue, 22 Oct 2024 16:54:11 -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 Tue, Oct 22, 2024 at 04:09:33PM +0200, Sebastian Andrzej Siewior wrote:
> On 2024-10-21 09:48:03 [-0700], Paul E. McKenney wrote:
> > > 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.  ;-)
> 
> For LAZIEST PeterZ added "do we want this?". I haven't tested this but
> since there is no forced preemption at all, it should be what is NONE
> without cond_resched() & friends. So I don't know if it stays, I don't
> think so.

I don't know of a compelling reason for it to.

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

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

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

							Thanx, Paul