Re: [PATCH RFC tip/core/rcu] SRCU rewrite

[Paul E. McKenney]

On Tue, Nov 15, 2016 at 02:59:12PM +0100, Peter Zijlstra wrote:
> On Tue, Nov 15, 2016 at 01:54:50PM +0000, Mathieu Desnoyers wrote:
> > ----- On Nov 15, 2016, at 2:51 AM, Peter Zijlstra peterz@xxxxxxxxxxxxx wrote:
> > 
> > > On Mon, Nov 14, 2016 at 10:36:36AM -0800, Paul E. McKenney wrote:
> > >> SRCU uses two per-cpu counters: a nesting counter to count the number of
> > >> active critical sections, and a sequence counter to ensure that the nesting
> > >> counters don't change while they are being added together in
> > >> srcu_readers_active_idx_check().
> > >> 
> > >> This patch instead uses per-cpu lock and unlock counters. Because the both
> > >> counters only increase and srcu_readers_active_idx_check() reads the unlock
> > >> counter before the lock counter, this achieves the same end without having
> > >> to increment two different counters in srcu_read_lock(). This also saves a
> > >> smp_mb() in srcu_readers_active_idx_check().
> > > 
> > > A very small improvement... I feel SRCU has much bigger issues :/
> > 
> > Do you have specific issues in mind ?
> 
> The smp_mb()s in read_{un,}lock() and the lock in call_srcu() come to
> mind.

There is some possibility of weakening the srcu_read_unlock() ordering,
but one step at a time.

Has the lock in call_srcu() been causing trouble?  Easy to fix if so,
but as you noted in another email today, we don't need complexity for
complexity's sake.  And no reports of problems with this have reached
me thus far.

							Thanx, Paul