On Thu, Oct 08, 2015 at 07:12:03PM +0200, Peter Zijlstra wrote:
> On Thu, Oct 08, 2015 at 08:33:51AM -0700, Paul E. McKenney wrote:
>
> > > > 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! ;-)
>
> This is a whole different line of reasoning once again.
>
> The point remains, that the sole purpose of the barrier upgrade is for
> the tree iteration, having some extra (pointless but harmless) instances
> does not detract from that.
>
> > Fair enough, but I will be sticking to the simple coding rule that keeps
> > RCU out of trouble!
>
> Note that there are rnp->lock acquires without the extra barrier though,
> so you seem somewhat inconsistent with your own rule.
>
> See for example:
>
> rcu_dump_cpu_stacks()
> print_other_cpu_stall()
> print_cpu_stall()
>
> (did not do an exhaustive scan, there might be more)
>
> and yes, that is 'obvious' debug code and not critical to the correct
> behaviour of the code, but it is a deviation from 'the rule'.
Which I need to fix, thank you.
Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
