public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: josh@joshtriplett.org
To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: linux-kernel@vger.kernel.org, mingo@kernel.org,
	laijs@cn.fujitsu.com, dipankar@in.ibm.com,
	akpm@linux-foundation.org, mathieu.desnoyers@efficios.com,
	tglx@linutronix.de, peterz@infradead.org, rostedt@goodmis.org,
	dhowells@redhat.com, edumazet@google.com, dvhart@linux.intel.com,
	fweisbec@gmail.com, oleg@redhat.com, bobby.prani@gmail.com
Subject: Re: [PATCH RFC tip/core/rcu 0/5] Expedited grace periods encouraging normal ones
Date: Tue, 30 Jun 2015 16:46:33 -0700	[thread overview]
Message-ID: <20150630234633.GA11450@cloud> (raw)
In-Reply-To: <20150630221224.GQ3717@linux.vnet.ibm.com>

On Tue, Jun 30, 2015 at 03:12:24PM -0700, Paul E. McKenney wrote:
> On Tue, Jun 30, 2015 at 03:00:15PM -0700, josh@joshtriplett.org wrote:
> > On Tue, Jun 30, 2015 at 02:48:05PM -0700, Paul E. McKenney wrote:
> > > Hello!
> > > 
> > > This series contains some highly experimental patches that allow normal
> > > grace periods to take advantage of the work done by concurrent expedited
> > > grace periods.  This can reduce the overhead incurred by normal grace
> > > periods by eliminating the need for force-quiescent-state scans that
> > > would otherwise have happened after the expedited grace period completed.
> > > It is not clear whether this is a useful tradeoff.  Nevertheless, this
> > > series contains the following patches:
> > 
> > While it makes sense to avoid unnecessarily delaying a normal grace
> > period if the expedited machinery has provided the necessary delay, I'm
> > also *deeply* concerned that this will create a new class of
> > nondeterministic performance issues.  Something that uses RCU may
> > perform badly due to grace period latency, but then suddenly start
> > performing well because an unrelated task starts hammering expedited
> > grace periods.  This seems particularly likely during boot, for
> > instance, where RCU grace periods can be a significant component of boot
> > time (when you're trying to boot to userspace in small fractions of a
> > second).
> 
> I will take that as another vote against.  And for a reason that I had
> not yet come up with, so good show!  ;-)

Consider it a fairly weak concern against.  Increasing performance seems
like a good thing in general; I just don't relish the future "feels less
responsive" bug reports that take a long time to track down and turn out
to be "this completely unrelated driver was loaded and started using
expedited grace periods".

Then again, perhaps the more relevant concern would be why drivers use
expedited grace periods in the first place.

- Josh Triplett

  reply	other threads:[~2015-06-30 23:46 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-30 21:48 [PATCH RFC tip/core/rcu 0/5] Expedited grace periods encouraging normal ones Paul E. McKenney
2015-06-30 21:48 ` [PATCH RFC tip/core/rcu 1/5] rcu: Prepare for expedited GP driving normal GP Paul E. McKenney
2015-06-30 21:48   ` [PATCH RFC tip/core/rcu 2/5] rcu: Short-circuit normal GPs via expedited GPs Paul E. McKenney
2015-07-01 10:03     ` Peter Zijlstra
2015-07-01 13:42       ` Paul E. McKenney
2015-07-01 20:59       ` Paul E. McKenney
2015-07-01 10:05     ` Peter Zijlstra
2015-07-01 13:41       ` Paul E. McKenney
2015-07-01 13:48         ` Peter Zijlstra
2015-07-01 14:03           ` Paul E. McKenney
2015-07-02 12:03             ` Peter Zijlstra
2015-07-02 14:06               ` Paul E. McKenney
2015-07-02 16:48                 ` Peter Zijlstra
2015-07-02 19:35                   ` Paul E. McKenney
2015-07-06 14:52                     ` Peter Zijlstra
2015-06-30 21:48   ` [PATCH RFC tip/core/rcu 3/5] rcutorture: Ensure that normal GPs advance without " Paul E. McKenney
2015-06-30 21:48   ` [PATCH RFC tip/core/rcu 4/5] rcu: Wake grace-period kthread at end of expedited grace period Paul E. McKenney
2015-06-30 21:48   ` [PATCH RFC tip/core/rcu 5/5] rcu: Limit expedited helping to every 10 ms or every 4th GP Paul E. McKenney
2015-06-30 21:56     ` Eric Dumazet
2015-06-30 22:10       ` Paul E. McKenney
2015-07-01 10:07     ` Peter Zijlstra
2015-07-01 13:45       ` Paul E. McKenney
2015-07-01 19:30       ` Paul E. McKenney
2015-06-30 22:00 ` [PATCH RFC tip/core/rcu 0/5] Expedited grace periods encouraging normal ones josh
2015-06-30 22:12   ` Paul E. McKenney
2015-06-30 23:46     ` josh [this message]
2015-07-01  0:15       ` Paul E. McKenney
2015-07-01  0:42         ` Josh Triplett
2015-07-01  3:37           ` Paul E. McKenney
2015-07-01 10:12             ` Peter Zijlstra
2015-07-01 14:01               ` Paul E. McKenney
2015-07-01 14:08                 ` Eric Dumazet
2015-07-01 15:58                   ` Paul E. McKenney
2015-07-01 15:43             ` Josh Triplett
2015-07-01 15:59               ` Paul E. McKenney
2015-07-01 10:09       ` Peter Zijlstra
2015-07-01 10:55         ` Peter Zijlstra
2015-07-01 14:00           ` Paul E. McKenney
2015-07-01 14:17             ` Peter Zijlstra
2015-07-01 16:17               ` Paul E. McKenney
2015-07-01 17:02                 ` Peter Zijlstra
2015-07-01 20:09                   ` Paul E. McKenney
2015-07-01 21:20                     ` josh
2015-07-01 21:49                       ` Paul E. McKenney
2015-07-02  7:47                     ` Ingo Molnar
2015-07-02 13:58                       ` Paul E. McKenney
2015-07-02 18:35                         ` Ingo Molnar
2015-07-02 18:47                           ` Mathieu Desnoyers
2015-07-02 19:23                             ` Paul E. McKenney
2015-07-02 21:07                               ` Mathieu Desnoyers
2015-07-02 19:22                           ` Paul E. McKenney
2015-07-02  1:11                 ` Mike Galbraith
2015-07-02  1:34                   ` josh
2015-07-02  1:59                     ` Mike Galbraith
2015-07-02  2:18                       ` Paul E. McKenney
2015-07-02  2:50                         ` Mike Galbraith
2015-07-02  3:15                           ` 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=20150630234633.GA11450@cloud \
    --to=josh@joshtriplett.org \
    --cc=akpm@linux-foundation.org \
    --cc=bobby.prani@gmail.com \
    --cc=dhowells@redhat.com \
    --cc=dipankar@in.ibm.com \
    --cc=dvhart@linux.intel.com \
    --cc=edumazet@google.com \
    --cc=fweisbec@gmail.com \
    --cc=laijs@cn.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mingo@kernel.org \
    --cc=oleg@redhat.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    /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