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: <20241009205218.GW17263@noisy.programming.kicks-ass.net>
Date: Wed, 9 Oct 2024 22:52:18 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: "Paul E. McKenney" <paulmck@...nel.org>
Cc: Ankur Arora <ankur.a.arora@...cle.com>, linux-kernel@...r.kernel.org,
	tglx@...utronix.de, mingo@...nel.org, bigeasy@...utronix.de,
	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 Wed, Oct 09, 2024 at 11:24:09AM -0700, Paul E. McKenney wrote:
> On Wed, Oct 09, 2024 at 08:01:17PM +0200, Peter Zijlstra wrote:
> > On Wed, Oct 09, 2024 at 09:54:06AM -0700, Ankur Arora wrote:
> > > PREEMPT_LAZY can be enabled stand-alone or alongside PREEMPT_DYNAMIC
> > > which allows for dynamic switching of preemption models.
> > > 
> > > The choice of preemptible RCU or not, however, is fixed at compile
> > > time. Given the trade-offs made to have a preemptible RCU, some
> > > configurations which have limited preemption might prefer the
> > > stronger forward-progress guarantees of PREEMPT_RCU=n.
> > > 
> > > Accordingly, explicitly limit PREEMPT_RCU=y to PREEMPT_DYNAMIC,
> > > PREEMPT, PREEMPT_RT.
> > > 
> > > This means that (PREEMPT_LAZY=y, PREEMPT_DYNAMIC=n), which selects
> > > PREEMPTION will run with PREEMPT_RCU=n. The combination (PREEMPT_LAZY=y,
> > > PREEMPT_DYNAMIC=y), will run with PREEMPT_RCU=y.
> > 
> > I am completely confused by this. Why do we want this?
> 
> In order to support systems that currently run CONFIG_PREEMPT=n that
> are adequately but not overly endowed with memory.  If we allow all
> RCU readers to be preempted, we increase grace-period latency, and also
> increase OOM incidence.  Which we would like to avoid.
> 
> But we do want lazy preemption otherwise, for but one thing to reduce
> tail latencies and to reduce the need for preemption points.  Thus, we
> want a way to allow lazy preemption in general, but to continue with
> non-preemptible RCU read-side critical sections.
> 
> Or am I once again missing your point?

Even without this patch this is allowed, right? It's just a default
that's changed. If people want to run PREEMPT_RCU=n, they can select it.

I just don't see a point in making this change.