LWN: Comments on "The design of preemptible read-copy-update"

The design of preemptible read-copy-update

firolwn — Tue, 26 Mar 2019 06:05:36 +0000

Could anyone help me to understand the following sentence?
In contrast to SRCU, preemptible RCU only permits blocking within primitives that are both subject to priority inheritance and non-blocking in a non-CONFIG_PREEMPT kernel.

Quick Quiz 8 : interrupt would also have had to have occurred after the rcu_read_lock()

Neeraju — Mon, 21 Nov 2016 11:50:56 +0000

Hi, for cases where rcu_dereference is reordered before rcu_read_lock(), I didn't get how interrupt occuring after rcu_dereference, also implies that, interrupt should have happened after rcu_read_lock. Can you please help understand?

The design of preemptible read-copy-update

rednoah — Sun, 23 Oct 2016 02:11:48 +0000

>Of course, if the RCU read-side critical section has been preempted, rcu_read_lock() might be decrementing the counter
it should be rcu_read_unlock from context

The design of preemptible read-copy-update

PaulMcKenney — Thu, 11 Oct 2007 23:50:42 +0000

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.

The design of preemptible read-copy-update

i3839 — Thu, 11 Oct 2007 12:00:20 +0000

Good and very detailed article.

Are there any benchmarks which show how it compares to normal RCU?