* Paolo Bonzini ([email protected]) 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 _______________________________________________ ltt-dev mailing list [email protected] http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
