All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	Julia Cartwright <julia@ni.com>,
	Luiz Capitulino <lcapitulino@redhat.com>,
	linux-rt-users@vger.kernel.org
Subject: Re: Making rcu_normal=1 in RT
Date: Mon, 31 Oct 2016 19:52:40 -0700	[thread overview]
Message-ID: <20161101025240.GR3716@linux.vnet.ibm.com> (raw)
In-Reply-To: <20161101043508-mutt-send-email-mst@kernel.org>

On Tue, Nov 01, 2016 at 04:36:54AM +0200, Michael S. Tsirkin wrote:
> On Mon, Oct 31, 2016 at 07:19:41PM -0700, Paul E. McKenney wrote:
> > On Tue, Nov 01, 2016 at 12:37:04AM +0200, Michael S. Tsirkin wrote:
> > > On Mon, Oct 31, 2016 at 11:15:43AM -0700, Paul E. McKenney wrote:
> > > > On Mon, Oct 31, 2016 at 06:38:52PM +0100, Sebastian Andrzej Siewior wrote:
> > > > > On 2016-10-16 04:28:46 [-0700], Paul E. McKenney wrote:
> > > > > > If the relevant maintainers are OK with that, I am OK with it as long
> > > > > > as it is non-default (at least to begin with) and does not introduce
> > > > > > additional Kconfig questions.  My guess is that a boot parameter would
> > > > > > work best, but something to discuss.
> > > > > 
> > > > > Okay. For me to summary:
> > > > > - we want rcu_normal_after_boot=1 on -RT via CONFIG_PREEMPT_RT_FULL
> > > > 
> > > > That would be good.
> > > > 
> > > > > - this makes synchronize_rcu_expedited() behave like
> > > > >   synchronize_rcu() and therefore I can drop all patches replacing
> > > > >   synchronize_rcu_expedited() with synchronize_rcu().
> > > > 
> > > > And this would be a benefit.  ;-)
> > > > 
> > > > > - optionally it has been requested to make synchronize_rcu() behave like
> > > > >   synchronize_rcu_expedited() on shutdown and kexec().
> > > > 
> > > > You can invoke rcu_unexpedite_gp() to force all subsequennt grace periods
> > > > to be expedited, but you do need to clear rcu_normal for this to have
> > > > effect.  Right now, that means "WRITE_ONCE(rcu_normal, 0)", but I could
> > > > easily supply a formal API if you would prefer.  Which you probably
> > > > would given  that TINY_RCU doesn't have rcu_normal...
> > > > 
> > > > > Did I miss understood / forgot something?
> > > > 
> > > > It would not hurt to boot with rcu_expedited if boot speed is critical,
> > > > but I don't know whether or not this should be enabled by default.
> > > > 
> > > > 							Thanx, Paul
> > > 
> > > I don't know either but I'd like to know ATM it's expedited
> > > by default.
> > 
> > In current mainline, no.  That is, rcu_expedited=0 by default.
> > 
> > Or am I missing the point of your question?
> > 
> > 							Thanx, Paul
> 
> That's true - what I meant is that adding and removing network devices
> happens on boot and calls synchronize_rcu_expedited,
> with the commit log explaining that this is done for speeding up boot
> and shutdown.

The rcu_normal boot parameter will indeed nullify this optimization.
The boot parameters are normally dumped into dmesg, which should allow
determining when this has happened.  But I do still feel like I am not
fully understanding your concern.

							Thanx, Paul


  reply	other threads:[~2016-11-01  2:52 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 [this message]
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-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=20161101025240.GR3716@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 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.