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: <37af80bd-a54f-4ee4-9175-6f0f27b685a0@paulmck-laptop>
Date: Wed, 9 Oct 2024 11:24:09 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Peter Zijlstra <peterz@...radead.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 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?

							Thanx, Paul

> > Cc: Paul E. McKenney <paulmck@...nel.org>
> > Cc: Peter Zijlstra <peterz@...radead.org>
> > Signed-off-by: Ankur Arora <ankur.a.arora@...cle.com>
> > ---
> >  kernel/rcu/Kconfig | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/kernel/rcu/Kconfig b/kernel/rcu/Kconfig
> > index 3e079de0f5b4..1bfe7016724f 100644
> > --- a/kernel/rcu/Kconfig
> > +++ b/kernel/rcu/Kconfig
> > @@ -18,7 +18,7 @@ config TREE_RCU
> >  
> >  config PREEMPT_RCU
> >  	bool
> > -	default y if PREEMPTION
> > +	default y if (PREEMPT || PREEMPT_RT || PREEMPT_DYNAMIC)
> >  	select TREE_RCU
> >  	help
> >  	  This option selects the RCU implementation that is
> > -- 
> > 2.43.5
> >