[ltt-dev] [RFC PATCH 0/7] priority-boost urcu

[Mathieu Desnoyers]

* Paolo Bonzini (pbonzini at redhat.com) wrote:
> On 08/17/2011 07:31 AM, Mathieu Desnoyers wrote:
>> So I guess that in that sense, synchronize_rcu() of MB and QSBR could be
>> merged, is that what you are trying to get at ? (sorry for being slow on
>> the uptake);-)
>
> Yes, and perhaps MEMBARRIER too---leaving just SIGNAL as the oddball  
> one.  That's also why I started doing the futex optimization in QSBR.
>
> Did you measure SIGNAL to have better performance in practice than MB?

Yep. See, under http://www.efficios.com/publications "User-Level
Implementations of Read-Copy Update" main paper, Figure 4 on page 4. It
compares read-side scalability of QSBR vs signal-based RCU vs
General-purpose RCU (which we call MB here), along with others.
Signal-based performs significantly better than the general-purpose
version, because we can turn the memory barriers on the rcu read
lock/unlock sites into simple compiler barriers.

Note that if we ever get a sys_membarrier system call merged into the
Linux kernel, I'd be willing to replace the signal-based RCU support by
the sys_membarrier version as a drop-in replacement, because the latter
has the same read-side performance as signal-based, is much simpler in
terms of user-space implementation, and does not require any signal
number.

Thoughts ?

Thanks,

Mathieu

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com