On Tue, May 11, 2010 at 09:14:04AM -0400, Mathieu Desnoyers wrote: > * John Kacur (jkacur@xxxxxxxxxx) wrote: > > On Tue, May 11, 2010 at 2:21 PM, Mathieu Desnoyers > > <mathieu.desnoyers@xxxxxxxxxxxx> wrote: > > > Hi Thomas, > > > > > > Paul told me you were quite interested in the userspace RCU library when he told > > > you about it (http://lttng.org/urcu). Do you have some userspace applications or > > > libraries with real-time needs in mind that could use it ? We could help moving > > > them to liburcu. The wait-free read-side is, as you certainly know, a > > > characteristic of RCU that can be very useful to RT applications. > > > > > > [CCing linux-rt-users, as it seems appropriate to ask them too.] > > > > > > Thanks, > > > > Do you have any kind of benchmarks? If you had something appropriate > > we could add it to the rt-tests suite (which includes cyclictest). Not > > only would this provide an objective measure, but it could also act as > > a reference implementation for userspace programmers. > > Yes, the library already has its set of benchmark test programs. The results can > be found in http://lttng.org/pub/thesis/desnoyers-dissertation-2009-12.pdf > section 6.5. It shows that RCU read-side is a few orders of magnitude faster > than lock-based approaches and scales linearly with the number of cores. > > The same PDF, sections 7.6.2 and 7.6.3, presents the architecture-level modeling > of the RCU mb algorithm in Promela, along with the formal proof by model > checking for both correctness and progress (the read-side is proven wait-free). > > > > > See here. > > git clone git://git.kernel.org/pub/scm/linux/kernel/git/clrkwllms/rt-tests.git > > > > cyclictest is the original program written by Thomas, maintained by > > Clark Williams now. Most - but not all, of the additional tests are > > modelled after this program, so you might want to have a look at that > > if you're not already familiar with it. > > Thanks for the pointer, I did know about cyclictest, but not the others. Since > the read-side does not involve the OS nor blocking, I wonder which of these > tests would be even a near-match though. Why not add mutual-exclusion tests, including locking, per-thread locking, reader-writer locking, and RCU? The figure of merit would be maximum latency rather than throughput, but the existing userspace-rcu tests should be pretty close. Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
