關于RCU-sched的研究

對于synchronize_rcu原理的研究，在現(xiàn)在的源碼中發(fā)現(xiàn)：

* When synchronize_rcu() is invoked on one CPU while other CPUs* are within RCU read-side critical sections, then the* synchronize_rcu() is guaranteed to block until after all the other* CPUs exit their critical sections. Similarly, if call_rcu() is invoked* on one CPU while other CPUs are within RCU read-side critical* sections, invocation of the corresponding RCU callback is deferred* until after the all the other CPUs exit their critical sections.

也就是說一個CPU的synchronize_rcu需要等待其他所有CPU都脫離RCU read-side臨界區(qū)！

* In non-preemptible RCU implementations (pure TREE_RCU and TINY_RCU),* it is illegal to block while in an RCU read-side critical section.* In preemptible RCU implementations (PREEMPT_RCU) in CONFIG_PREEMPTION* kernel builds, RCU read-side critical sections may be preempted,* but explicit blocking is illegal. Finally, in preemptible RCU* implementations in real-time (with -rt patchset) kernel builds, RCU* read-side critical sections may be preempted and they may also block, but* only when acquiring spinlocks that are subject to priority inheritance.

也就是說其實是有可搶占版的RCU的！

可搶占的RCU

如果config文件定義了CONFIG_TREE_PREEMPT_RCU=y，那么sychronize_rcu將默認使用rcu_preempt_state（sychronize_rcu）。這類rcu的特點就在于read_lock期間是允許其它進程搶占的，因此它判斷寬限期度過的方法就不太一樣。

從rcu_read_lock和rcu_read_unlock的定義就可以知道，TREE_PREEMPT_RCU并不是以簡單的經(jīng)過搶占為CPU渡過GP的標準，而是有個rcu_read_lock_nesting計數(shù)

在lwn文章中詳細介紹了不同的內核配置導致RCU的不同：

• CONFIG_PREEMPT=n and CONFIG_SMP=y implies CONFIG_TREE_RCU, selecting the non-preemptible tree-based RCU implementation that is appropriate for server-class SMP builds. It can accommodate a very large number of CPUs, but scales down sufficiently well for all but the most memory-constrained systems.
• CONFIG_PREEMPT=y implies CONFIG_TREE_PREEMPT_RCU, selecting the preemptible tree-based RCU implementation that is appropriate for real-time and low-latency SMP builds. It can also accommodate a very large number of CPUs, and also scales down sufficiently well for all but the most memory-constrained systems. The boot parameters for CONFIG_TREE_RCU also apply to CONFIG_TREE_PREEMPT_RCU.
• CONFIG_PREEMPT=n and CONFIG_SMP=n implies CONFIG_TINY_RCU, selecting the non-preemptible uniprocessor RCU implementation that is appropriate for non-real-time UP builds. It has the smallest memory footprint of any of the current in-kernel RCU implementations. In fact, its memory footprint is so small that it doesn’t even have any kernel boot parameters.

也就是說，CONFIG_PREEMPT=n內核用的是不可搶占RCU，而CONFIG_PREEMPT=y implies CONFIG_TREE_PREEMPT_RCU，所以CONFIG_PREEMPT=y用的是可搶占的RCU。查了下我自己的電腦，是CONFIG_PREEMPT_VOLUNTARY=y，因此用的是不可搶占內核！對于不可搶占的RCU來說，RCU和RCU-Sched是一樣的，因為反正都是不可搶占。而對于可搶占的RCU來說，RCU是可以搶占的，而RCU-Sched是不可搶占！官方文檔中介紹了Sched-Favor的RCU：
“Note well that in CONFIG_PREEMPT=y kernels, rcu_read_lock_sched() and rcu_read_unlock_sched() disable and re-enable preemption, respectively.” 也就是說，RCU-sched在CONFIG_PREEMPT=y的情況下，rcu_read_lock_sched()是關搶占的！

因此，在RCU中_sched API后綴的意義僅僅體現(xiàn)在當CONFIG_PREEMPT=y也就是將內核配置為可搶占的情況！在CONFIG_PREEMPT=y情況下，RCU read-side臨界區(qū)是可搶占的，而RCU-sched read-side是不可搶占的！

在lwn文章中還討論的一個RCU和RCU-Sched混用的問題：

Quick Quiz 3: What happens if you mix and match RCU and RCU-Sched?

假如我們把RCU和RCU-Sched混合使用了怎么辦？

Answer: In a CONFIG_TREE_RCU or a CONFIG_TINY_RCU kernel, mixing these two works “by accident” because in those kernel builds, RCU and RCU-Sched map to the same implementation.

對于CONFIG_TREE_RCU or a CONFIG_TINY_RCU=y的內核來說，混用兩者無所謂，因為在這種內核里RCU和RCU-Sched的實現(xiàn)是相同的

However, this mixture is fatal in CONFIG_TREE_PREEMPT_RCU builds, due to the fact that RCU’s read-side critical sections can then be preempted, which would permit synchronize_sched() to return before the RCU read-side critical section reached its rcu_read_unlock() call.

但是對于CONFIG_TREE_PREEMPT_RCU=y的內核來說，其RCU read-side是可以被搶占的，那么假如讀端用的rcu_read_lock/unlock在寫端使用synchronize_sched，讀端的臨界區(qū)發(fā)生搶占就會提前結束其寬限期（其實并沒有）

This could, in turn, result in a data structure being freed before the read-side critical section was finished with it, which could, in turn, greatly increase the actuarial risk experienced by your kernel.

這可能會導致讀者還沒讀完，寫者就free掉了其讀的內存，導致風險！

Even in CONFIG_TREE_RCU and CONFIG_TINY_RCU builds, such mixing and matching is of course very strongly discouraged. Mixing and matching other flavors of RCU is even worse: it can result in hard-to-debug bad-pointer bugs.

總結

以上是生活随笔為你收集整理的关于RCU-sched的研究的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。