From: "Paul E. McKenney" <paulmck@kernel.org>
To: Joel Fernandes <joel@joelfernandes.org>
Cc: Frederic Weisbecker <frederic@kernel.org>,
Uladzislau Rezki <urezki@gmail.com>,
"Zhuo, Qiuxu" <qiuxu.zhuo@intel.com>,
linux-kernel@vger.kernel.org,
Lai Jiangshan <jiangshanlai@gmail.com>,
linux-doc@vger.kernel.org, rcu@vger.kernel.org
Subject: Re: [PATCH RFC v2] rcu: Add a minimum time for marking boot as completed
Date: Wed, 1 Mar 2023 16:49:31 -0800 [thread overview]
Message-ID: <20230302004931.GM2948950@paulmck-ThinkPad-P17-Gen-1> (raw)
In-Reply-To: <CAEXW_YTt=VZ8ZMptccFMStsQvfjy5yMbd5Ah3KL=PUB4YVSTCg@mail.gmail.com>
On Wed, Mar 01, 2023 at 04:31:01PM -0500, Joel Fernandes wrote:
> On Wed, Mar 1, 2023 at 12:11 PM Frederic Weisbecker <frederic@kernel.org> wrote:
> [...]
> > > Hmmm I see what you mean, so a conservative and configurable "fail-safe"
> > > timeout followed by sysctl to end the boot earlier than the timeout, should
> > > do it (something like 30 seconds IMHO sounds reasonable)? In any case,
> > > whatever way we go, we would not end the kernel boot before
> > > rcu_end_inkernel_boot() is called at least once (which is the current
> > > behavior).
> > >
> > > So it would be:
> > >
> > > low level boot + initcalls
> > > 20 sec 30 second timeout
> > > |------------------------------|--------------------------
> > > | |
> > > old rcu_end_inkernel_boot() new rcu_end_inkernel_boot()
> > >
> > > But it could be, if user decides:
> > > low level boot + initcalls
> > > 20 sec 10 second timeout
> > > |------------------------------|--------------------------
> > > | |
> > > old rcu_end_inkernel_boot() new rcu_end_inkernel_boot()
> > > via /sys/ entry.
> >
> > The problem I have with a random default timeout is that it may break sensitive
> > workloads. If the default is 30 and say the boot only takes 5 seconds and
> > immediately launches a latency sensitive task, this may break things in a
> > subtle way during these 25 seconds when it usually didn't. Because expedited
> > RCU is a hammer interrupting all non-idle CPUs.
> >
> > Until now forcing expedited RCU was only performed before any user code. Now it
> > crosses the boundary so better be careful. I'd personally advocate for keeping
> > the current call before init is launched. Then provide an end_boot_sysctl kernel
> > boot parameter that will ignore the current call before init and let the user
> > signal that through sysctl.
>
> Considering that the PREEMPT-RT system benefits from it within the 8
> seconds, I will go ahead make the default 15 seconds or so and make it
> tunable. Hopefully that will be an acceptable compromise, with
> sufficient documentation, changelog, and so forth... If you agree I'd
> appreciate your Ack on the next posting.
Just checking on the sysfs portion of this. After all, tuning kernel
boot parameters to specific systems is not all that much fun, especially
when you have lots of systems.
Thanx, Paul
next prev parent reply other threads:[~2023-03-02 0:49 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-25 3:34 [PATCH RFC v2] rcu: Add a minimum time for marking boot as completed Joel Fernandes (Google)
2023-02-25 3:36 ` Randy Dunlap
2023-02-26 19:45 ` Frederic Weisbecker
2023-02-26 23:07 ` Joel Fernandes
2023-02-27 7:53 ` Zhuo, Qiuxu
2023-02-27 13:22 ` Joel Fernandes
2023-02-27 14:55 ` Paul E. McKenney
2023-02-27 15:16 ` Joel Fernandes
2023-02-27 18:06 ` Uladzislau Rezki
2023-02-27 18:15 ` Joel Fernandes
2023-02-27 18:20 ` Uladzislau Rezki
2023-02-27 18:27 ` Joel Fernandes
2023-02-27 18:57 ` Uladzislau Rezki
2023-02-27 19:10 ` Joel Fernandes
2023-02-27 23:05 ` Paul E. McKenney
2023-02-27 23:24 ` Joel Fernandes
2023-02-27 23:40 ` Frederic Weisbecker
2023-02-28 1:30 ` Joel Fernandes
2023-02-28 11:04 ` Frederic Weisbecker
2023-02-28 20:09 ` Joel Fernandes
2023-03-01 17:11 ` Frederic Weisbecker
2023-03-01 21:31 ` Joel Fernandes
2023-03-02 0:49 ` Paul E. McKenney [this message]
2023-03-02 1:08 ` Joel Fernandes
2023-03-02 1:19 ` Paul E. McKenney
2023-02-28 11:42 ` Uladzislau Rezki
2023-02-28 6:40 ` Zhuo, Qiuxu
2023-02-28 14:27 ` Joel Fernandes
2023-03-01 1:34 ` Zhuo, Qiuxu
2023-03-01 15:57 ` Joel Fernandes
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=20230302004931.GM2948950@paulmck-ThinkPad-P17-Gen-1 \
--to=paulmck@kernel.org \
--cc=frederic@kernel.org \
--cc=jiangshanlai@gmail.com \
--cc=joel@joelfernandes.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=qiuxu.zhuo@intel.com \
--cc=rcu@vger.kernel.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