All of lore.kernel.org
 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 09:53:24 -0700	[thread overview]
Message-ID: <20210916165324.GG4156@paulmck-ThinkPad-P17-Gen-1> (raw)
In-Reply-To: <YUNUQ564PKq9wtTF@hirez.programming.kicks-ass.net>

On Thu, Sep 16, 2021 at 04:27:15PM +0200, Peter Zijlstra wrote:
> On Thu, Sep 16, 2021 at 06:57:12AM -0700, Paul E. McKenney wrote:
> > 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?
> 
> That wasn't at all clear to me from the Changelog. I thought it was
> enabling expedited crud for RT.

This paragraph of the current commit log covers that point:

	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.

Does that cover it from your viewpoint?  If not, any suggested changes
for clarification?

							Thanx, Paul

  reply	other threads:[~2021-09-16 17:52 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
2021-09-16 14:27       ` Peter Zijlstra
2021-09-16 16:53         ` Paul E. McKenney [this message]
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=20210916165324.GG4156@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 \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.