[lttng-dev] Practical recommendation for max update rate with QSBR

Mathieu Desnoyers mathieu.desnoyers at efficios.com
Thu Jul 21 21:58:29 UTC 2016


----- On Jul 21, 2016, at 4:47 PM, Mark E. Dawson <medawsonjr at yahoo.com> wrote: 

> All,

> I've read the documentation regarding reader throughput drop-offs with high
> update rates due to the pointer exchanging between readers-writers, and the
> general admonition of using URCU only for mostly-read workloads with relatively
> infrequent updates.

> However, is there a general rule-of-thumb suggestion for highest recommended
> update rate sustainable for optimal performance with URCU (in particular, the
> QSBR flavor) for highly threaded applications deployed on high core count
> machines (Intel)? The example case would be a single updater and 20 - 30 reader
> threads.

Hi Mark, 

We have some relevant measurements in the supplementary material of: 

Desnoyers, Mathieu, McKenney, Paul. E., Stern, Alan S., Dagenais, Michel R. and Walpole, Jonathan, User-Level Implementations of Read-Copy Update . IEEE Transaction on Parallel and Distributed Systems , 23 (2): 375-382 (2012). 

A copy can be found at http://www.efficios.com/publications 

See p. 10 of supplementary material, Fig. 14: 

"Comparison of Pointer Exchange and Ideal RCU Update Overhead, 8-core Intel Xeon, Logarithmic Scale" 

Since you are doing pointer exchange, you will want to look at the "QSBR" 
line, which stays at 1000M reads/s up to 100000 updates/s, and then starts 
dropping. 

On the 64-core POWER5+ (Fig. 15), read speed starts dropping near 100000 
updates/s too. 

Thanks, 

Mathieu 

> _______________________________________________
> lttng-dev mailing list
> lttng-dev at lists.lttng.org
> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

-- 
Mathieu Desnoyers 
EfficiOS Inc. 
http://www.efficios.com 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.lttng.org/pipermail/lttng-dev/attachments/20160721/f6fc2844/attachment.html>


More information about the lttng-dev mailing list