| Weekly edition | Kernel | Security | Distributions | Search |
| Archives | Calendar | Subscribe | Write for LWN | LWN.net FAQ |
The design of preemptible read-copy-update
The design of preemptible read-copy-update
Posted Oct 11, 2007 12:00 UTC (Thu) by i3839 (subscriber, #31386)Parent article: The design of preemptible read-copy-update
Good and very detailed article.
Are there any benchmarks which show how it compares to normal RCU?
(Log in to post comments)
The design of preemptible read-copy-update
Posted Oct 11, 2007 23:50 UTC (Thu) by PaulMcKenney (subscriber, #9624) [Link]
On the read side, the new CONFIG_PREEMPT_RT implementation is about double the overhead of the CONFIG_PREEMPT variant of RCU. Of course your mileage will vary depending on your hardware -- this is on a recent Opteron.
The benchmarks for grace-period latency are obsolete, since they used four (rather than two) stages of grace-period processing. And of course, kudos to Steve Rostedt for convincing me to check whether four stages was really required!
This update-side latency can be avoided by using call_rcu() rather that synchronize_rcu(), but synchronize_rcu() is still preferable in most cases due to its simplicity and ease of use.