[ltt-dev] [RFC] Lock-free RCU queue for userspace RCU library
Mathieu Desnoyers
mathieu.desnoyers at efficios.com
Tue Jul 13 12:07:51 EDT 2010
* Paolo Bonzini (pbonzini at redhat.com) wrote:
> On 07/12/2010 06:32 AM, Mathieu Desnoyers wrote:
>> So, I think I found a neat way to handle lock-free rcu queues with
>> reference counting instead. Note that the "dummy" node is really
>> needed, otherwise we end up in situations where the "empty" queue is
>> hard to deal with racelessly. FYI, the ABA problem is dealt with by
>> using rcu read locks. Comments on the code below are very welcome.
>
> There is a problem with reference counting: the neat part of my
> implementation was that I only needed to do a grace period after a few
> thousands allocations. As it is now, the implementation of urcu_ref.h
> would synchronize on every allocation, which obviously kills performance.
Nope, we don't need to do that :-) Thanks to the defer_rcu() mechanism, we can
batch grace periods. So the typical use-case is:
release_fct(struct urcu_ref *ref)
{
struct rcu_lfq_node *node = container_of(ref, struct rcu_lfq_node, ref);
defer_rcu(free, node);
}
enqueuer:
node = malloc()
enqueue(q, node)
dequeuer:
node = dequeue(q, release_fct);
use node...
urcu_ref_put(&node->ref, release_fct);
Typically, defer_rcu() will do a synchronize_rcu() only once every 4096
invocations from a given thread, or each 100ms (whichever comes first).
>
> So, maybe a page-slicing allocator can be bundled with URCU that layers
> my technique on top of some other allocator. Being on vacation I won't
> do that for a couple of weeks, but I can do that if there is interest.
>
> Otherwise, it looks great.
Thanks for taking time to look into that. Enjoy your vacation!
Mathieu
>
> Paolo
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
More information about the lttng-dev
mailing list