From: Joel Fernandes <joel@joelfernandes.org>
To: paulmck@kernel.org
Cc: Uladzislau Rezki <urezki@gmail.com>,
Qais Yousef <qyousef@layalina.io>,
Frederic Weisbecker <frederic@kernel.org>,
Neeraj Upadhyay <quic_neeraju@quicinc.com>,
Josh Triplett <josh@joshtriplett.org>,
Boqun Feng <boqun.feng@gmail.com>,
Steven Rostedt <rostedt@goodmis.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Lai Jiangshan <jiangshanlai@gmail.com>,
Zqiang <qiang.zhang1211@gmail.com>,
Andrea Righi <andrea.righi@canonical.com>,
John Stultz <jstultz@google.com>,
linux-kernel@vger.kernel.org, rcu@vger.kernel.org
Subject: Re: [PATCH v2] rcu: Provide a boot time parameter to control lazy RCU
Date: Fri, 15 Dec 2023 17:47:57 -0500 [thread overview]
Message-ID: <CAEXW_YRcYvhpXXWYCb+_W9rB-0tFqXDgNUtR8+Ug=P4iOt7JBQ@mail.gmail.com> (raw)
In-Reply-To: <f1a6e96e-43d7-4872-9db5-c43bc767bf9e@paulmck-laptop>
On Fri, Dec 15, 2023 at 1:46 PM Paul E. McKenney <paulmck@kernel.org> wrote:
>
> On Fri, Dec 15, 2023 at 05:58:55PM +0100, Uladzislau Rezki wrote:
> > Hello, Joel!
> >
> > > [....]
> > > > > > > + Use rcutree.enable_rcu_lazy=0 to turn it off at boot time.
> > > > > > > +
> > > > > > > +config RCU_LAZY_DEFAULT_OFF
> > > > > > > + bool "Turn RCU lazy invocation off by default"
> > > > > > > + depends on RCU_LAZY
> > > > > > > + default n
> > > > > > > + help
> > > > > > > + Allows building the kernel with CONFIG_RCU_LAZY=y yet keep it default
> > > > > > > + off. Boot time param rcutree.enable_rcu_lazy=1 can be used to switch
> > > > > > > + it back on.
> > > > > > > +
> > > > > > > config RCU_DOUBLE_CHECK_CB_TIME
> > > > > > > bool "RCU callback-batch backup time check"
> > > > > > > depends on RCU_EXPERT
> > > > > > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> > > > > > > index 3ac3c846105f..8b7675624815 100644
> > > > > > > --- a/kernel/rcu/tree.c
> > > > > > > +++ b/kernel/rcu/tree.c
> > > > > > > @@ -2719,6 +2719,9 @@ __call_rcu_common(struct rcu_head *head, rcu_callback_t func, bool lazy_in)
> > > > > > > }
> > > > > > >
> > > > > > > #ifdef CONFIG_RCU_LAZY
> > > > > > > +static bool enable_rcu_lazy __read_mostly = !IS_ENABLED(CONFIG_RCU_LAZY_DEFAULT_OFF);
> > > > > > > +module_param(enable_rcu_lazy, bool, 0444);
> > > > > > > +
> > > > > > > /**
> > > > > > > * call_rcu_hurry() - Queue RCU callback for invocation after grace period, and
> > > > > > > * flush all lazy callbacks (including the new one) to the main ->cblist while
> > > > > > > @@ -2744,6 +2747,8 @@ void call_rcu_hurry(struct rcu_head *head, rcu_callback_t func)
> > > > > > > __call_rcu_common(head, func, false);
> > > > > > > }
> > > > > > > EXPORT_SYMBOL_GPL(call_rcu_hurry);
> > > > > > > +#else
> > > > > > > +#define enable_rcu_lazy false
> > > > > > > #endif
> > > > > > >
> > > > > > > /**
> > > > > > > @@ -2792,7 +2797,7 @@ EXPORT_SYMBOL_GPL(call_rcu_hurry);
> > > > > > > */
> > > > > > > void call_rcu(struct rcu_head *head, rcu_callback_t func)
> > > > > > > {
> > > > > > > - __call_rcu_common(head, func, IS_ENABLED(CONFIG_RCU_LAZY));
> > > > > > > + __call_rcu_common(head, func, enable_rcu_lazy);
> > > > > > > }
> > > > > > > EXPORT_SYMBOL_GPL(call_rcu);
> > > > > > >
> > > > > > I think, it makes sense. Especially for devices/systems where it is hard
> > > > > > to recompile the kernel and deploy it. For example, Google and GKI approach.
> > > > >
> > > > > My concerns had nothing to do with recompiling the kernel. Passing a
> > > > > boot parameter (without a kernel compile) can just as well
> > > > > default-disable the feature.
> > > > >
> > > > > I think what Qais is saying is that passing a boot parameter is itself
> > > > > a hassle in Android (something I did not know about) because of GKI
> > > > > etc.
> > > > >
> > > > That is true. Doing:
> > > >
> > > > echo 1 > /sys/.../enable_lazy
> > > >
> > > > is a way how to make it easy and flexible.
> > >
> > > Hey Vlad, are you suggesting that the boot parameter be made to
> > > support runtime? We can keep that for later as it may get complicated.
> > > Qais's boot parameter is designed only for boot time.
> > >
> > No problem. Yes, i meant a runtime one. But as you stated there might
> > be hidden issues witch we are not aware of yet.
>
> My current thought is that Qais's version currently in -rcu for
> the merge window after next (v6.9) suits our current situation.
> But if we are eventually able to support runtime changes to this new
> rcutree.enable_rcu_lazy module parameter via simplification to the
> rcu_nocb_try_bypass() function (or maybe a better analysis of it),
> then at that point it would be good to allow this module parameter to
> be changed via sysfs at runtime.
Yes, that's right.
> Does that make sense, or am I missing some aspect or use case?
No you are not missing anything.
Thanks.
prev parent reply other threads:[~2023-12-15 22:48 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-03 1:12 [PATCH v2] rcu: Provide a boot time parameter to control lazy RCU Qais Yousef
2023-12-03 13:18 ` Andrea Righi
2023-12-05 4:27 ` Paul E. McKenney
2023-12-05 16:20 ` Joel Fernandes
2023-12-07 17:20 ` Qais Yousef
2023-12-09 6:26 ` Joel Fernandes
2023-12-12 12:05 ` Qais Yousef
2023-12-12 22:32 ` Joel Fernandes
2023-12-12 12:35 ` Uladzislau Rezki
2023-12-12 22:28 ` Joel Fernandes
2023-12-13 10:35 ` Uladzislau Rezki
2023-12-15 16:32 ` Joel Fernandes
2023-12-15 16:58 ` Uladzislau Rezki
2023-12-15 18:46 ` Paul E. McKenney
2023-12-15 22:47 ` Joel Fernandes [this message]
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='CAEXW_YRcYvhpXXWYCb+_W9rB-0tFqXDgNUtR8+Ug=P4iOt7JBQ@mail.gmail.com' \
--to=joel@joelfernandes.org \
--cc=andrea.righi@canonical.com \
--cc=boqun.feng@gmail.com \
--cc=frederic@kernel.org \
--cc=jiangshanlai@gmail.com \
--cc=josh@joshtriplett.org \
--cc=jstultz@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=paulmck@kernel.org \
--cc=qiang.zhang1211@gmail.com \
--cc=quic_neeraju@quicinc.com \
--cc=qyousef@layalina.io \
--cc=rcu@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=urezki@gmail.com \
/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 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 read-only IMAP folder(s) and NNTP newsgroup(s).