rcu.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: rcu@vger.kernel.org, linux-kernel@vger.kernel.org,
	kernel-team@fb.com, mingo@kernel.org, jiangshanlai@gmail.com,
	akpm@linux-foundation.org, mathieu.desnoyers@efficios.com,
	josh@joshtriplett.org, tglx@linutronix.de, rostedt@goodmis.org,
	dhowells@redhat.com, edumazet@google.com, fweisbec@gmail.com,
	oleg@redhat.com, joel@joelfernandes.org,
	Juri Lelli <juri.lelli@redhat.com>
Subject: Re: [PATCH rcu 11/14] rcu: Make rcu_normal_after_boot writable again
Date: Thu, 16 Sep 2021 06:57:12 -0700	[thread overview]
Message-ID: <20210916135712.GB4156@paulmck-ThinkPad-P17-Gen-1> (raw)
In-Reply-To: <YULyiT+RbAgHxO7u@hirez.programming.kicks-ass.net>

On Thu, Sep 16, 2021 at 09:30:17AM +0200, Peter Zijlstra wrote:
> On Wed, Sep 15, 2021 at 04:33:40PM -0700, Paul E. McKenney wrote:
> > From: Juri Lelli <juri.lelli@redhat.com>
> > 
> > Certain configurations (e.g., systems that make heavy use of netns)
> > need to use synchronize_rcu_expedited() to service RCU grace periods
> > even after boot.
> > 
> > Even though synchronize_rcu_expedited() has been traditionally
> > considered harmful for RT for the heavy use of IPIs, it is perfectly
> > usable under certain conditions (e.g. nohz_full).
> > 
> > Make rcupdate.rcu_normal_after_boot= again writeable on RT (if NO_HZ_
> > FULL is defined), but keep its default value to 1 (enabled) to avoid
> > regressions. Users who need synchronize_rcu_expedited() will boot with
> > rcupdate.rcu_normal_after_ boot=0 in the kernel cmdline.
> > 
> > Reflect the change in synchronize_rcu_expedited_wait() by removing the
> > WARN related to CONFIG_PREEMPT_RT.
> > 
> > Signed-off-by: Juri Lelli <juri.lelli@redhat.com>
> > Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
> > ---
> >  kernel/rcu/tree_exp.h | 1 -
> >  kernel/rcu/update.c   | 2 +-
> >  2 files changed, 1 insertion(+), 2 deletions(-)
> > 
> > diff --git a/kernel/rcu/tree_exp.h b/kernel/rcu/tree_exp.h
> > index 2796084ef85a..d9e4f8eb9ae2 100644
> > --- a/kernel/rcu/tree_exp.h
> > +++ b/kernel/rcu/tree_exp.h
> > @@ -512,7 +512,6 @@ static void synchronize_rcu_expedited_wait(void)
> >  		j = READ_ONCE(jiffies_till_first_fqs);
> >  		if (synchronize_rcu_expedited_wait_once(j + HZ))
> >  			return;
> > -		WARN_ON_ONCE(IS_ENABLED(CONFIG_PREEMPT_RT));
> >  	}
> >  
> >  	for (;;) {
> 
> Urgh... I really don't like this. That would force RT applications to
> always use NOHZ_FULL which isn't always possible or desired.

???

RT systems they avoid expedited grace periods by booting with either
the rcupdate.rcu_normal or the rcupdate.rcu_normal_after_boot kernel
boot parameters.  And here is the definition for the latter:

static int rcu_normal_after_boot = IS_ENABLED(CONFIG_PREEMPT_RT);

In other words, RT systems shut off expedited grace periods by default,
and are thus free to use nohz_full CPU or not, as they choose.  When using
nohz_full, they can also enable expedited grace periods by booting with
rcupdate.rcu_normal_after_boot=0.  Or not, sysadm's choice.

So I am not seeing a problem here.  What am I missing?

> WTH does that netns crud need expedited so much?

Large systems with lots of networking configurations can take quite some
time to set things up due to waiting for many grace periods.  In addition,
last I checked, expedited grace periods were used to reduce contention
on RTNL.

If you have a modest-sized system with less elaborate networking setup
and make use of the batched network-configuration mechanisms, there
should be no problem using normal grace periods.

Which has been the set of constraints that RT has been living with for
quite some time.

Again, what am I missing?

							Thanx, Paul

  reply	other threads:[~2021-09-16 13:57 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-15 23:33 [PATCH rcu 0/14] Miscellaneous fixes for v5.16 Paul E. McKenney
2021-09-15 23:33 ` [PATCH rcu 01/14] rcu: Mark accesses to rcu_state.n_force_qs Paul E. McKenney
2021-09-15 23:33 ` [PATCH rcu 02/14] rcu-nocb: Fix a couple of tree_nocb code-style nits Paul E. McKenney
2021-09-15 23:33 ` [PATCH rcu 03/14] rcu: Eliminate rcu_implicit_dynticks_qs() local variable rnhqp Paul E. McKenney
2021-09-15 23:33 ` [PATCH rcu 04/14] rcu: Eliminate rcu_implicit_dynticks_qs() local variable ruqp Paul E. McKenney
2021-09-15 23:33 ` [PATCH rcu 05/14] doc: Add another stall-warning root cause in stallwarn.rst Paul E. McKenney
2021-09-15 23:33 ` [PATCH rcu 06/14] rcu: Fix undefined Kconfig macros Paul E. McKenney
2021-09-15 23:33 ` [PATCH rcu 07/14] rcu: Comment rcu_gp_init() code waiting for CPU-hotplug operations Paul E. McKenney
2021-09-15 23:33 ` [PATCH rcu 08/14] rcu: Move rcu_dynticks_eqs_online() to rcu_cpu_starting() Paul E. McKenney
2021-09-15 23:33 ` [PATCH rcu 09/14] rcu: Simplify rcu_report_dead() call to rcu_report_exp_rdp() Paul E. McKenney
2021-09-15 23:33 ` [PATCH rcu 10/14] rcu: Make rcutree_dying_cpu() use its "cpu" parameter Paul E. McKenney
2021-09-16  7:28   ` Peter Zijlstra
2021-09-15 23:33 ` [PATCH rcu 11/14] rcu: Make rcu_normal_after_boot writable again Paul E. McKenney
2021-09-16  7:30   ` Peter Zijlstra
2021-09-16 13:57     ` Paul E. McKenney [this message]
2021-09-16 14:27       ` Peter Zijlstra
2021-09-16 16:53         ` Paul E. McKenney
2021-09-15 23:33 ` [PATCH rcu 12/14] rcu: Make rcu update module parameters world-readable Paul E. McKenney
2021-09-15 23:33 ` [PATCH rcu 13/14] rcu: Fix existing exp request check in sync_sched_exp_online_cleanup() Paul E. McKenney
2021-09-15 23:33 ` [PATCH rcu 14/14] rcu: Avoid unneeded function call in rcu_read_unlock() Paul E. McKenney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210916135712.GB4156@paulmck-ThinkPad-P17-Gen-1 \
    --to=paulmck@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=dhowells@redhat.com \
    --cc=edumazet@google.com \
    --cc=fweisbec@gmail.com \
    --cc=jiangshanlai@gmail.com \
    --cc=joel@joelfernandes.org \
    --cc=josh@joshtriplett.org \
    --cc=juri.lelli@redhat.com \
    --cc=kernel-team@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mingo@kernel.org \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rcu@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --subject='Re: [PATCH rcu 11/14] rcu: Make rcu_normal_after_boot writable again' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).