From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
Julia Cartwright <julia@ni.com>,
Luiz Capitulino <lcapitulino@redhat.com>,
linux-rt-users@vger.kernel.org,
Josh Triplett <josh@joshtriplett.org>,
Steven Rostedt <rostedt@goodmis.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Lai Jiangshan <jiangshanlai@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] rcu: update: make RCU_EXPEDITE_BOOT default
Date: Thu, 3 Nov 2016 09:59:31 -0700 [thread overview]
Message-ID: <20161103165931.GJ3716@linux.vnet.ibm.com> (raw)
In-Reply-To: <20161103163326.jkjbncoz7a5oriy5@linutronix.de>
On Thu, Nov 03, 2016 at 05:33:27PM +0100, Sebastian Andrzej Siewior wrote:
> On 2016-11-03 09:22:28 [-0700], Paul E. McKenney wrote:
> > On Wed, Nov 02, 2016 at 05:30:02PM +0100, Sebastian Andrzej Siewior wrote:
> > > RCU_EXPEDITE_BOOT should speed up the boot process by enforcing
> > > synchronize_rcu_expedited() instead of synchronize_rcu() during the boot
> > > process. There should be no reason why one does not want this and there
> > > is no need worry about real time latency at this point.
> > > Therefore make it default.
> > >
> > > Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> >
> > Well, it has been awhile since I removed a Kconfig parameter.
> >
> > So why could this be a bad thing?
> >
> > 1. Very large systems might see scalability issues with unconditional
> > expediting at boot. But if we don't try it, we won't know.
>
> You mean we would make the boot process slower for them instead of
> faster?
For really bit systems, quite possibly, where "really big" means
many hundreds or (more likely) thousands of CPUs.
But there are things that I can do to fix this when and if.
> > 2. People bringing up new hardware might not want quite so many
> > IPIs. But they can just set rcu_normal to prevent that.
>
> I wanted to make things simple and not complicated…
I know that feeling. ;-)
> > I am therefore queuing it for testiong and review. ;-)
>
> Okay thanks.
Thanx, Paul
> Sebastian
>
next prev parent reply other threads:[~2016-11-03 16:59 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-12 15:12 Making rcu_normal=1 in RT Luiz Capitulino
2016-10-12 16:21 ` Julia Cartwright
2016-10-12 16:39 ` Paul E. McKenney
2016-10-12 16:49 ` Luiz Capitulino
2016-10-12 17:15 ` Julia Cartwright
2016-10-12 20:32 ` Paul E. McKenney
2016-10-13 16:25 ` Michael S. Tsirkin
2016-10-14 9:20 ` Paul E. McKenney
2016-10-16 1:45 ` Michael S. Tsirkin
2016-10-16 11:28 ` Paul E. McKenney
2016-10-31 17:38 ` Sebastian Andrzej Siewior
2016-10-31 18:15 ` Paul E. McKenney
2016-10-31 22:37 ` Michael S. Tsirkin
2016-11-01 2:19 ` Paul E. McKenney
2016-11-01 2:36 ` Michael S. Tsirkin
2016-11-01 2:52 ` Paul E. McKenney
2016-11-01 3:31 ` Michael S. Tsirkin
2016-11-02 16:05 ` Sebastian Andrzej Siewior
2016-11-03 16:26 ` Paul E. McKenney
2016-11-02 16:30 ` [PATCH] rcu: update: make RCU_EXPEDITE_BOOT default Sebastian Andrzej Siewior
2016-11-03 16:22 ` Paul E. McKenney
2016-11-03 16:33 ` Sebastian Andrzej Siewior
2016-11-03 16:59 ` Paul E. McKenney [this message]
2016-11-07 17:19 ` Steven Rostedt
2016-11-07 17:30 ` Sebastian Andrzej Siewior
2016-11-07 17:35 ` Josh Triplett
2016-11-07 18:05 ` Paul E. McKenney
2016-11-07 18:08 ` Josh Triplett
2016-11-07 19:04 ` Paul E. McKenney
2016-11-09 6:26 ` [rcu] c6908ba082: INFO: rcu_sched detected expedited stalls on CPUs/tasks: { 0-... } 26689 jiffies s: 9 root: 0x1/ kernel test robot
2016-11-02 16:51 ` Making rcu_normal=1 in RT Sebastian Andrzej Siewior
2016-11-02 17:41 ` Luiz Capitulino
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=20161103165931.GJ3716@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=bigeasy@linutronix.de \
--cc=jiangshanlai@gmail.com \
--cc=josh@joshtriplett.org \
--cc=julia@ni.com \
--cc=lcapitulino@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mst@redhat.com \
--cc=rostedt@goodmis.org \
/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.