From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Julia Cartwright <julia@ni.com>
Cc: Luiz Capitulino <lcapitulino@redhat.com>,
linux-rt-users@vger.kernel.org, bigeasy@linutronix.de,
mst@redhat.com
Subject: Re: Making rcu_normal=1 in RT
Date: Wed, 12 Oct 2016 13:32:23 -0700 [thread overview]
Message-ID: <20161012203223.GK29518@linux.vnet.ibm.com> (raw)
In-Reply-To: <20161012171553.GA18392@jcartwri.amer.corp.natinst.com>
On Wed, Oct 12, 2016 at 12:15:53PM -0500, Julia Cartwright wrote:
> On Wed, Oct 12, 2016 at 12:49:56PM -0400, Luiz Capitulino wrote:
> > On Wed, 12 Oct 2016 11:21:14 -0500
> > Julia Cartwright <julia@ni.com> wrote:
> >
> > > On Wed, Oct 12, 2016 at 11:12:51AM -0400, Luiz Capitulino wrote:
> > > > Hi,
> > > >
> > > > We have the following patch applied to the RT tree:
> > > >
> > > > commit a9d3cc781a3306bfa332fa7cb6134b70696058d5
> > > > Author: Josh Cartwright <joshc@ni.com>
> > > > Date: Tue Oct 27 07:31:53 2015 -0500
> > > >
> > > > net: Make synchronize_rcu_expedited() conditional on !RT_FULL
> > > >
> > > > However, as noted by Michael, making rcu_normal=1 default in the
> > > > RT kernel should have the same effect (ie. not calling
> > > > synchronize_sched_expedited()).
> > > >
> > > > So, honest question, is there a reason not to:
> > > >
> > > > 1. Drop the patch above
> > > > 2. Make rcu_normal=1 default?
> > >
> > > I think this is probably a cleaner way to fix the problems which
> > > motivated this patch in the first place. In my defense, the above patch
> > > predates rcu_normal :).
> >
> > No need to defend yourself! We debugged this very spike in one of
> > our kernels that don't have rcu_normal. We decided to do exactly
> > what you're doing before looking at upstream. Your patch helped
> > us confirm that we were in the right track.
>
> Great! Glad I could help in some way!
>
> > > Something like this, perhaps?
> >
> > Looks good, but (honest question) what does it buy us using
> > rcu_normal_after_boot vs rcu_normal? Is the boot process
> > improved someway?
>
> That's the idea, although I don't have data to show much it actually
> buys us.
It means that grace periods can be expedited during boot. If you really
care about boot speed, you can also set rcu_expedited=1 and also
rcu_normal_after_boot=1, which will expedite all grace periods during
the boot process, but stop doing so just before spawning init.
After that point, any attempt to do an expedited grace period gets you
a normal grace period instead.
So you get fast boot and then clean realtime.
> > As long as we're rcu_normal=1 before launching user-space,
> > this should be fine.
>
> Agreed.
Yes, you can also set them manually instead of at boot, if you wish.
Thanx, Paul
next prev parent reply other threads:[~2016-10-12 20:32 UTC|newest]
Thread overview: 31+ 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 [this message]
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
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-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=20161012203223.GK29518@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=bigeasy@linutronix.de \
--cc=julia@ni.com \
--cc=lcapitulino@redhat.com \
--cc=linux-rt-users@vger.kernel.org \
--cc=mst@redhat.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 NNTP newsgroup(s).