All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Mike Galbraith <efault@gmx.de>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: TREE_SRCU slows hotplug by factor ~16
Date: Tue, 25 Apr 2017 15:36:42 -0700	[thread overview]
Message-ID: <20170425223642.GA10931@linux.vnet.ibm.com> (raw)
In-Reply-To: <20170424162442.GI3956@linux.vnet.ibm.com>

On Mon, Apr 24, 2017 at 09:24:42AM -0700, Paul E. McKenney wrote:
> On Mon, Apr 24, 2017 at 09:35:03AM +0200, Mike Galbraith wrote:
> > On Sun, 2017-04-23 at 23:22 -0700, Paul E. McKenney wrote:
> > 
> > > Could you please collect an ftrace (or whatever) showing the timestamp
> > > sequence of calls to synchronize_srcu(), synchronize_srcu_expedited(),
> > > and call_srcu() during the execution of the stress script?  If it is easy
> > > to do, also the timestamp sequence of returns from synchronize_srcu()
> > > and synchronize_srcu_expedited()?
> > 
> > The first two minutes below config bits, trace_printk([enter/exit]) in
> > each function.  If you (unlikely, but..) want the whole trace, holler.
> > 
> > # RCU Subsystem
> > CONFIG_TREE_RCU=y
> > CONFIG_RCU_EXPERT=y
> > CONFIG_SRCU=y
> > # CONFIG_CLASSIC_SRCU is not set
> > CONFIG_TREE_SRCU=y
> > # CONFIG_TASKS_RCU is not set
> > CONFIG_RCU_STALL_COMMON=y
> > CONFIG_RCU_FANOUT=64
> > CONFIG_RCU_FANOUT_LEAF=16
> > # CONFIG_RCU_FAST_NO_HZ is not set
> > # CONFIG_TREE_RCU_TRACE is not set
> > CONFIG_RCU_KTHREAD_PRIO=0
> > CONFIG_RCU_NOCB_CPU=y
> > CONFIG_RCU_NOCB_CPU_NONE=y
> > # CONFIG_RCU_NOCB_CPU_ZERO is not set
> > # CONFIG_RCU_NOCB_CPU_ALL is not set
> > # RCU Debugging
> > # CONFIG_PROVE_RCU is not set
> > # CONFIG_SPARSE_RCU_POINTER is not set
> > # CONFIG_RCU_PERF_TEST is not set
> > # CONFIG_RCU_TORTURE_TEST is not set
> > CONFIG_RCU_CPU_STALL_TIMEOUT=60
> > # CONFIG_RCU_TRACE is not set
> > # CONFIG_RCU_EQS_DEBUG is not set
> 
> Thank you for the data, extremely helpful!  I now know that I must
> immediately fix this the hard way rather than trying several simpler
> possibilities that, according to your trace data, would be complete
> wastes of time.
> 
> My initial calculation was actually optimistic.  There was one
> exit-to-enter interval at about 80 milliseconds, but the second
> longest is 342 microseconds, and the vast majority are under 200
> microseconds.
> 
> Back to the drawing board!
> 
> This will take some time, but I should have a patch for you in a few days,
> hopefully sooner.

Making progress, might have something late tomorrow (Wednesday) Pacific
Time, will definitely have something Thursday Pacific Time.

								Thanx, Paul

  reply	other threads:[~2017-04-25 22:37 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-24  2:48 TREE_SRCU slows hotplug by factor ~16 Mike Galbraith
2017-04-24  3:32 ` Paul E. McKenney
2017-04-24  5:24   ` Mike Galbraith
2017-04-24  6:22     ` Paul E. McKenney
2017-04-24  7:35       ` Mike Galbraith
2017-04-24  8:43         ` Mike Galbraith
2017-04-24 16:24         ` Paul E. McKenney
2017-04-25 22:36           ` Paul E. McKenney [this message]
2017-04-26 14:31             ` Paul E. McKenney
2017-04-26 15:26               ` Mike Galbraith
2017-04-26 15:44                 ` Paul E. McKenney
2017-04-26 15:49                   ` Mike Galbraith
2017-04-26 16:00                     ` Paul E. McKenney
2017-04-26 17:45                     ` Mike Galbraith
2017-04-26 17:55                       ` Paul E. McKenney
2017-04-26 17:56                         ` Paul E. McKenney
2017-04-26 18:12                           ` Mike Galbraith
2017-04-26 18:25                             ` Paul E. McKenney
2017-04-27  3:43                             ` Mike Galbraith
2017-04-27  4:11                               ` Paul E. McKenney
2017-04-27  4:15                                 ` Mike Galbraith
2017-04-27  5:32                                   ` Paul E. McKenney
2017-04-27  5:44                                     ` Mike Galbraith
2017-04-27 12:37                                       ` Paul E. McKenney

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=20170425223642.GA10931@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=efault@gmx.de \
    --cc=linux-kernel@vger.kernel.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.