Re: [PATCH tip/core/rcu 02/18] rcu: Move rcu_report_exp_rnp() to allow consolidation

From	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Newsgroups	linux.kernel
Subject	Re: [PATCH tip/core/rcu 02/18] rcu: Move rcu_report_exp_rnp() to allow consolidation
Date	2015-10-08 17:40 +0200
Message-ID	<qhlsu-7EU-13@gated-at.bofh.it> (permalink)
References	(5 earlier) <qgRNM-6WR-7@gated-at.bofh.it> <qgY2R-7BV-7@gated-at.bofh.it> <qgYcy-7Ng-7@gated-at.bofh.it> <qh04G-25n-5@gated-at.bofh.it> <qhfZL-88e-1@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

On Thu, Oct 08, 2015 at 11:49:33AM +0200, Peter Zijlstra wrote:
> On Wed, Oct 07, 2015 at 09:48:58AM -0700, Paul E. McKenney wrote:
> 
> > > Some implementation choice requires this barrier upgrade -- and in
> > > another email I suggest its the whole tree thing, we need to firmly
> > > establish the state of one level before propagating the state up etc.
> > > 
> > > Now I'm not entirely sure this is fully correct, but its the best I
> > > could come up.
> > 
> > It is pretty close.  Ignoring dyntick idle for the moment, things
> > go (very) roughly like this:
> > 
> > o	The RCU grace-period kthread notices that a new grace period
> > 	is needed.  It initializes the tree, which includes acquiring
> > 	every rcu_node structure's ->lock.
> > 
> > o	CPU A notices that there is a new grace period.  It acquires
> > 	the ->lock of its leaf rcu_node structure, which forces full
> > 	ordering against the grace-period kthread.
> 
> If the kthread took _all_ rcu_node locks, then this does not require the
> barrier upgrade because they will share a lock variable.
> 
> > o	Some time later, that CPU A realizes that it has passed
> > 	through a quiescent state, and again acquires its leaf rcu_node
> > 	structure's ->lock, again enforcing full ordering, but this
> > 	time against all CPUs corresponding to this same leaf rcu_node
> > 	structure that previously noticed quiescent states for this
> > 	same grace period.  Also against all prior readers on this
> > 	same CPU.
> 
> This again reads like the same lock variable is involved, and therefore
> the barrier upgrade is not required for this.
> 
> > o	Some time later, CPU B (corresponding to that same leaf
> > 	rcu_node structure) is the last of that leaf's group of CPUs
> > 	to notice a quiescent state.  It has also acquired that leaf's
> > 	->lock, again forcing ordering against its prior RCU read-side
> > 	critical sections, but also against all the prior RCU
> > 	read-side critical sections of all other CPUs corresponding
> > 	to this same leaf.
> 
> same lock var again..
> 
> > o	CPU B therefore moves up the tree, acquiring the parent
> > 	rcu_node structures' ->lock.  In so doing, it forces full
> > 	ordering against all prior RCU read-side critical sections
> > 	of all CPUs corresponding to all leaf rcu_node structures
> > 	subordinate to the current (non-leaf) rcu_node structure.
> 
> And here we iterate the tree and get another lock var involved, here the
> barrier upgrade will actually do something.

Yep.  And I am way too lazy to sort out exactly which acquisitions really
truly need smp_mb__after_unlock_lock() and which don't.  Besides, if I
tried to sort it out, I would occasionally get it wrong, and this would be
a real pain to debug.  Therefore, I simply do smp_mb__after_unlock_lock()
on all acquisitions of the rcu_node structures' ->lock fields.  I can
actually validate that!  ;-)

> > o	And so on, up the tree.
> 
> idem..
> 
> > o	When CPU C reaches the root of the tree, and realizes that
> > 	it is the last CPU to report a quiescent state for the
> > 	current grace period, its acquisition of the root rcu_node
> > 	structure's ->lock has forced full ordering against all
> > 	RCU read-side critical sections that started before this
> > 	grace period -- on all CPUs.
> 
> Right, which makes the full barrier transitivity thing important
> 
> > 	CPU C therefore awakens the grace-period kthread.
> 
> > o	When the grace-period kthread wakes up, it does cleanup,
> > 	which (you guessed it!) requires acquiring the ->lock of
> > 	each rcu_node structure.  This not only forces full ordering
> > 	against each pre-existing RCU read-side critical section,
> > 	it also sets up things so that...
> 
> Again, if it takes _all_ rcu_nodes, it also shares a lock variable and
> hence the upgrade is not required.
> 
> > o	When CPU D notices that the grace period ended, it does so
> > 	while holding its leaf rcu_node structure's ->lock.  This
> > 	forces full ordering against all relevant RCU read-side
> > 	critical sections.  This ordering prevails when CPU D later
> > 	starts invoking RCU callbacks.
> 
> Does also not seem to require the upgrade..
> 
> > Hey, you asked!!!  ;-)
> 
> No, I asked what all the barrier upgrade was for, most of the above does
> not seem to rely on that at all.
> 
> The only place this upgrade matters is the UNLOCK x + LOCK y scenario,
> as also per the comment above smp_mb__after_unlock_lock().
> 
> Any other ordering is not on this but on the other primitives and
> irrelevant to the barrier upgrade.

I am still keeping an smp_mb__after_unlock_lock() after every ->lock.
Trying to track which needs it and which does not is asking for
subtle bugs.

> > Again, this is a cartoon-like view of the ordering that leaves out a
> > lot of details, but it should get across the gist of the ordering.
> 
> So the ordering I'm interested in, is the bit that is provided by the
> barrier upgrade, and that seems very limited and directly pertains to
> the tree iteration, ensuring its fully separated and transitive.
> 
> So I'll stick to explanation that the barrier upgrade is purely for the
> tree iteration, to separate and make transitive the tree level state.

Fair enough, but I will be sticking to the simple coding rule that keeps
RCU out of trouble!

							Thanx, Paul

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Thread

[PATCH tip/core/rcu 0/18] Expedited grace-period improvements for 4.4 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-10-06 18:30 +0200
  [PATCH tip/core/rcu 18/18] rcu: Better hotplug handling for synchronize_sched_expedited() "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-10-06 18:40 +0200
    Re: [PATCH tip/core/rcu 18/18] rcu: Better hotplug handling for  synchronize_sched_expedited() Peter Zijlstra <peterz@infradead.org> - 2015-10-07 16:30 +0200
      Re: [PATCH tip/core/rcu 18/18] rcu: Better hotplug handling for  synchronize_sched_expedited() "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-10-07 18:30 +0200
        Re: [PATCH tip/core/rcu 18/18] rcu: Better hotplug handling for  synchronize_sched_expedited() Peter Zijlstra <peterz@infradead.org> - 2015-10-08 11:10 +0200
          Re: [PATCH tip/core/rcu 18/18] rcu: Better hotplug handling for  synchronize_sched_expedited() "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-10-08 17:10 +0200
            Re: [PATCH tip/core/rcu 18/18] rcu: Better hotplug handling for  synchronize_sched_expedited() Peter Zijlstra <peterz@infradead.org> - 2015-10-08 17:20 +0200
              Re: [PATCH tip/core/rcu 18/18] rcu: Better hotplug handling for  synchronize_sched_expedited() "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-10-08 17:20 +0200
                Re: [PATCH tip/core/rcu 18/18] rcu: Better hotplug handling for  synchronize_sched_expedited() Josh Triplett <josh@joshtriplett.org> - 2015-10-08 20:10 +0200
                Re: [PATCH tip/core/rcu 18/18] rcu: Better hotplug handling for  synchronize_sched_expedited() "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-10-09 02:20 +0200
                Re: [PATCH tip/core/rcu 18/18] rcu: Better hotplug handling for  synchronize_sched_expedited() Josh Triplett <josh@joshtriplett.org> - 2015-10-09 02:50 +0200
                Re: [PATCH tip/core/rcu 18/18] rcu: Better hotplug handling for  synchronize_sched_expedited() "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-10-09 06:00 +0200
  [PATCH tip/core/rcu 10/18] rcu: Stop silencing lockdep false positive for expedited grace periods "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-10-06 18:40 +0200
  [PATCH tip/core/rcu 08/18] rcu: Make ->cpu_no_qs be a union for aggregate OR "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-10-06 18:40 +0200
  [PATCH tip/core/rcu 02/18] rcu: Move rcu_report_exp_rnp() to allow consolidation "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-10-06 18:40 +0200
    Re: [PATCH tip/core/rcu 02/18] rcu: Move rcu_report_exp_rnp() to  allow consolidation Peter Zijlstra <peterz@infradead.org> - 2015-10-06 22:30 +0200
      Re: [PATCH tip/core/rcu 02/18] rcu: Move rcu_report_exp_rnp() to  allow consolidation "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-10-06 23:00 +0200
        Re: [PATCH tip/core/rcu 02/18] rcu: Move rcu_report_exp_rnp() to  allow consolidation Peter Zijlstra <peterz@infradead.org> - 2015-10-07 10:00 +0200
          Re: [PATCH tip/core/rcu 02/18] rcu: Move rcu_report_exp_rnp() to  allow consolidation Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2015-10-07 10:50 +0200
            Re: [PATCH tip/core/rcu 02/18] rcu: Move rcu_report_exp_rnp() to  allow consolidation Peter Zijlstra <peterz@infradead.org> - 2015-10-07 13:10 +0200
              Re: [PATCH tip/core/rcu 02/18] rcu: Move rcu_report_exp_rnp() to  allow consolidation Peter Zijlstra <peterz@infradead.org> - 2015-10-07 14:00 +0200
                Re: [PATCH tip/core/rcu 02/18] rcu: Move rcu_report_exp_rnp() to  allow consolidation Peter Zijlstra <peterz@infradead.org> - 2015-10-07 14:10 +0200
                Re: Re: [PATCH tip/core/rcu 02/18] rcu: Move rcu_report_exp_rnp() to  allow consolidation kbuild test robot <lkp@intel.com> - 2015-10-07 14:10 +0200
                Re: Re: [PATCH tip/core/rcu 02/18] rcu: Move rcu_report_exp_rnp() to  allow consolidation kbuild test robot <lkp@intel.com> - 2015-10-07 14:10 +0200
                Re: Re: [PATCH tip/core/rcu 02/18] rcu: Move rcu_report_exp_rnp() to  allow consolidation Peter Zijlstra <peterz@infradead.org> - 2015-10-07 14:20 +0200
                Re: [kbuild-all] [PATCH tip/core/rcu 02/18] rcu: Move  rcu_report_exp_rnp() to allow consolidation Fengguang Wu <lkp@intel.com> - 2015-10-07 15:50 +0200
                Re: [kbuild-all] [PATCH tip/core/rcu 02/18] rcu: Move  rcu_report_exp_rnp() to allow consolidation Peter Zijlstra <peterz@infradead.org> - 2015-10-07 16:00 +0200
                Re: [kbuild-all] [PATCH tip/core/rcu 02/18] rcu: Move  rcu_report_exp_rnp() to allow consolidation Peter Zijlstra <peterz@infradead.org> - 2015-10-07 16:30 +0200
                Re: [kbuild-all] [PATCH tip/core/rcu 02/18] rcu: Move  rcu_report_exp_rnp() to allow consolidation Fengguang Wu <lkp@intel.com> - 2015-10-07 16:30 +0200
                Re: Re: [PATCH tip/core/rcu 02/18] rcu: Move rcu_report_exp_rnp() to  allow consolidation kbuild test robot <lkp@intel.com> - 2015-10-07 14:20 +0200
                Re: [PATCH tip/core/rcu 02/18] rcu: Move rcu_report_exp_rnp() to  allow consolidation "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-10-07 17:20 +0200
                Re: [PATCH tip/core/rcu 02/18] rcu: Move rcu_report_exp_rnp() to  allow consolidation Peter Zijlstra <peterz@infradead.org> - 2015-10-08 12:30 +0200
              Re: [PATCH tip/core/rcu 02/18] rcu: Move rcu_report_exp_rnp() to  allow consolidation "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-10-07 17:20 +0200
          Re: [PATCH tip/core/rcu 02/18] rcu: Move rcu_report_exp_rnp() to  allow consolidation "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-10-07 16:40 +0200
            Re: [PATCH tip/core/rcu 02/18] rcu: Move rcu_report_exp_rnp() to  allow consolidation Peter Zijlstra <peterz@infradead.org> - 2015-10-07 16:50 +0200
              Re: [PATCH tip/core/rcu 02/18] rcu: Move rcu_report_exp_rnp() to  allow consolidation "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-10-07 18:50 +0200
                Re: [PATCH tip/core/rcu 02/18] rcu: Move rcu_report_exp_rnp() to  allow consolidation Peter Zijlstra <peterz@infradead.org> - 2015-10-08 11:50 +0200
                Re: [PATCH tip/core/rcu 02/18] rcu: Move rcu_report_exp_rnp() to  allow consolidation "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-10-08 17:40 +0200
                Re: [PATCH tip/core/rcu 02/18] rcu: Move rcu_report_exp_rnp() to  allow consolidation Peter Zijlstra <peterz@infradead.org> - 2015-10-08 19:20 +0200
                Re: [PATCH tip/core/rcu 02/18] rcu: Move rcu_report_exp_rnp() to  allow consolidation "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-10-08 19:50 +0200
                Re: [PATCH tip/core/rcu 02/18] rcu: Move rcu_report_exp_rnp() to  allow consolidation "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-10-09 02:20 +0200
                Re: [PATCH tip/core/rcu 02/18] rcu: Move rcu_report_exp_rnp() to  allow consolidation Peter Zijlstra <peterz@infradead.org> - 2015-10-09 10:50 +0200
  [PATCH tip/core/rcu 05/18] rcu: Move synchronize_sched_expedited() to combining tree "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-10-06 18:40 +0200
  [PATCH tip/core/rcu 16/18] rcu: Add tasks to expedited stall-warning messages "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-10-06 18:40 +0200
  [PATCH tip/core/rcu 12/18] cpu: Remove try_get_online_cpus() "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-10-06 18:40 +0200
  [PATCH tip/core/rcu 03/18] rcu: Consolidate tree setup for synchronize_rcu_expedited() "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-10-06 18:40 +0200
  [PATCH tip/core/rcu 13/18] rcu: Prepare for consolidating expedited CPU selection "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-10-06 18:40 +0200
  [PATCH tip/core/rcu 07/18] rcu: Invert passed_quiesce and rename to cpu_no_qs "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-10-06 18:40 +0200
  [PATCH tip/core/rcu 04/18] rcu: Use single-stage IPI algorithm for RCU expedited grace period "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-10-06 18:40 +0200
    Re: [PATCH tip/core/rcu 04/18] rcu: Use single-stage IPI algorithm  for RCU expedited grace period Peter Zijlstra <peterz@infradead.org> - 2015-10-07 15:30 +0200
      Re: [PATCH tip/core/rcu 04/18] rcu: Use single-stage IPI algorithm  for RCU expedited grace period "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-10-07 20:20 +0200
    Re: [PATCH tip/core/rcu 04/18] rcu: Use single-stage IPI algorithm  for RCU expedited grace period Peter Zijlstra <peterz@infradead.org> - 2015-10-07 15:40 +0200
      Re: [PATCH tip/core/rcu 04/18] rcu: Use single-stage IPI algorithm  for RCU expedited grace period "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-10-07 17:50 +0200
    Re: [PATCH tip/core/rcu 04/18] rcu: Use single-stage IPI algorithm  for RCU expedited grace period Peter Zijlstra <peterz@infradead.org> - 2015-10-07 15:50 +0200
      Re: [PATCH tip/core/rcu 04/18] rcu: Use single-stage IPI algorithm  for RCU expedited grace period "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-10-07 18:20 +0200
        Re: [PATCH tip/core/rcu 04/18] rcu: Use single-stage IPI algorithm  for RCU expedited grace period Peter Zijlstra <peterz@infradead.org> - 2015-10-08 11:10 +0200
    Re: [PATCH tip/core/rcu 04/18] rcu: Use single-stage IPI algorithm  for RCU expedited grace period Peter Zijlstra <peterz@infradead.org> - 2015-10-07 15:50 +0200
      Re: [PATCH tip/core/rcu 04/18] rcu: Use single-stage IPI algorithm  for RCU expedited grace period "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-10-07 18:20 +0200
  [PATCH tip/core/rcu 09/18] rcu: Switch synchronize_sched_expedited() to IPI "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-10-06 18:40 +0200
    Re: [PATCH tip/core/rcu 09/18] rcu: Switch  synchronize_sched_expedited() to IPI Peter Zijlstra <peterz@infradead.org> - 2015-10-07 16:20 +0200
      Re: [PATCH tip/core/rcu 09/18] rcu: Switch  synchronize_sched_expedited() to IPI "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-10-07 18:30 +0200
  [PATCH tip/core/rcu 15/18] rcu: Add online/offline info to expedited stall warning message "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-10-06 18:40 +0200
  [PATCH tip/core/rcu 14/18] rcu: Consolidate expedited CPU selection "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-10-06 18:40 +0200
  [PATCH tip/core/rcu 01/18] rcu: Use rsp->expedited_wq instead of sync_rcu_preempt_exp_wq "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-10-06 18:40 +0200
    [PATCH tip/core/rcu 06/18] rcu: Rename qs_pending to core_needs_qs "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-10-06 18:40 +0200
    [PATCH tip/core/rcu 17/18] rcu: Enable stall warnings for synchronize_rcu_expedited() "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-10-06 18:40 +0200

csiph-web