[lttng-dev] [RFC PATCH urcu] Implement rcu_barrier()

[Paul E. McKenney]

On Wed, Jun 05, 2013 at 09:32:10AM -0400, Mathieu Desnoyers wrote:
> * Paul E. McKenney (paulmck at linux.vnet.ibm.com) wrote:
> > On Fri, May 31, 2013 at 11:35:17AM -0400, Mathieu Desnoyers wrote:
> [...]
> > > +
> > > +	if (work_count != count)
> > > +		uatomic_sub(&completion.barrier_count, count - work_count);
> > 
> > If we have a subset, we could do the rcu_barrier() one piece at a time.
> > Another approach would be to pre-allocate the call_rcu_completion_work
> > structure within the call_rcu_data structure.  I strongly recommend the
> > latter -- though this will of course result in serializing concurrent
> > rcu_barrier() invocations.
> 
> The issue I see with these approaches is that they require holding the
> call_rcu_mutex while waiting for completion. If a call_rcu thread ever
> needs to take the call_rcu_mutex (possibly caused by use of call_rcu in
> a call_rcu handler), this call_rcu thread could deadlock against the
> barrier.
> 
> Doing rcu_barrier() piecewise requires holding the call_rcu_mutex
> against traversal of call_rcu_data_list, and preallocation of
> call_rcu_completion_work within call_rcu_data requires the
> call_rcu_mutex to protect against call_rcu_data teardown.
> 
> By the way, we already have, in call_rcu_data_init():
> 
>         crdp = malloc(sizeof(*crdp));
>         if (crdp == NULL)
>                 urcu_die(errno);
> 
> So one possibility would be to make rcu_barrier() kill the process if
> out of memory (although I'd hate to have to do this).

That would be ugly, agreed, but it might be the best approach.
Presumably running out of memory is rare.

							Thanx, Paul

> Any suggestions ?
> 
> Thanks,
> 
> Mathieu
> 
> -- 
> Mathieu Desnoyers
> EfficiOS Inc.
> http://www.efficios.com
>