RCU 개념

파괴 연산의 두 단계

RCU의 기본 생각은 파괴적 연산을 둘로 나누는 것이다. 첫 단계는 삭제할 객체를 새 reader가 더는 보지 못하게 하고, 두 번째 단계는 실제 파괴를 수행한다. 두 단계 사이에는 삭제 전부터 객체를 참조하던 모든 reader가 참조를 놓을 만큼 긴 grace period가 필요하다.

RCU-protected 연결 리스트에서는 먼저 원소를 list에서 제거하고 grace period를 기다린 뒤 메모리를 해제한다. 자세한 list macro와 stale-data 패턴은 `listRCU.rst`가 설명한다.

.. _rcu_doc:

RCU Concepts
============

The basic idea behind RCU (read-copy update) is to split destructive
operations into two parts, one that prevents anyone from seeing the data
item being destroyed, and one that actually carries out the destruction.
A "grace period" must elapse between the two parts, and this grace period
must be long enough that any readers accessing the item being deleted have
since dropped their references.  For example, an RCU-protected deletion
from a linked list would first remove the item from the list, wait for
a grace period to elapse, then free the element.  See listRCU.rst for more
information on using RCU with linked lists.

자주 묻는 질문

RCU reader는 lock, atomic instruction, shared-memory write를 수행하지 않고 Alpha 이외 CPU에서는 memory barrier도 실행하지 않아 read-mostly workload에서 빠르다. Reader가 lock을 잡지 않는 점은 deadlock 회피도 단순하게 한다.

고전 RCU reader는 block, user mode 전환, idle loop 진입을 할 수 없다. 따라서 CPU가 context switch, user mode, idle 중 하나를 통과하면 그 CPU의 이전 reader가 끝났음을 안다. 모든 CPU가 이런 quiescent state를 통과하면 GP가 완료된다. Preemptible RCU와 SRCU는 CPU-local counter를 sample하며, SRCU는 reader의 일반 blocking도 허용한다.

Uniprocessor에서도 grace period가 필요한 이유는 `UP.rst`가 설명한다. Kernel 사용처는 `rcu_read_lock`, `rcu_read_unlock`, `call_rcu`, bh/SRCU/synchronize 계열 symbol을 검색해 찾을 수 있고, 작성 지침은 `checklist.rst`를 따른다.

RCU는 read-copy update의 약자이며 list의 copy-replace 예제가 이름을 직접 보여 준다. 관련 특허 중 일부는 lapse되었고 나머지는 GPL로 Linux에 제공되었으며 다수는 만료되었다. Userspace에는 LGPL `liburcu` 구현도 있다. 실시간 친화 RCU는 `CONFIG_PREEMPTION`으로 활성화한다.

Frequently Asked Questions
--------------------------

- Why would anyone want to use RCU?

  The advantage of RCU's two-part approach is that RCU readers need
  not acquire any locks, perform any atomic instructions, write to
  shared memory, or (on CPUs other than Alpha) execute any memory
  barriers.  The fact that these operations are quite expensive
  on modern CPUs is what gives RCU its performance advantages
  in read-mostly situations.  The fact that RCU readers need not
  acquire locks can also greatly simplify deadlock-avoidance code.

- How can the updater tell when a grace period has completed
  if the RCU readers give no indication when they are done?

  Just as with spinlocks, RCU readers are not permitted to
  block, switch to user-mode execution, or enter the idle loop.
  Therefore, as soon as a CPU is seen passing through any of these
  three states, we know that that CPU has exited any previous RCU
  read-side critical sections.  So, if we remove an item from a
  linked list, and then wait until all CPUs have switched context,
  executed in user mode, or executed in the idle loop, we can
  safely free up that item.

  Preemptible variants of RCU (CONFIG_PREEMPT_RCU) get the
  same effect, but require that the readers manipulate CPU-local
  counters.  These counters allow limited types of blocking within
  RCU read-side critical sections.  SRCU also uses CPU-local
  counters, and permits general blocking within RCU read-side
  critical sections.  These variants of RCU detect grace periods
  by sampling these counters.

- If I am running on a uniprocessor kernel, which can only do one
  thing at a time, why should I wait for a grace period?

  See UP.rst for more information.

- How can I see where RCU is currently used in the Linux kernel?

  Search for "rcu_read_lock", "rcu_read_unlock", "call_rcu",
  "rcu_read_lock_bh", "rcu_read_unlock_bh", "srcu_read_lock",
  "srcu_read_unlock", "synchronize_rcu", "synchronize_net",
  "synchronize_srcu", and the other RCU primitives.  Or grab one
  of the cscope databases from:

  (http://www.rdrop.com/users/paulmck/RCU/linuxusage/rculocktab.html).

- What guidelines should I follow when writing code that uses RCU?

  See checklist.rst.

- Why the name "RCU"?

  "RCU" stands for "read-copy update".
  listRCU.rst has more information on where this name came from, search
  for "read-copy update" to find it.

- I hear that RCU is patented?  What is with that?

  Yes, it is.  There are several known patents related to RCU,
  search for the string "Patent" in Documentation/RCU/RTFP.txt to find them.
  Of these, one was allowed to lapse by the assignee, and the
  others have been contributed to the Linux kernel under GPL.
  Many (but not all) have long since expired.
  There are now also LGPL implementations of user-level RCU
  available (https://liburcu.org/).

- I hear that RCU needs work in order to support realtime kernels?

  Realtime-friendly RCU are enabled via the CONFIG_PREEMPTION
  kernel configuration parameter.

- Where can I find more information on RCU?

  See the Documentation/RCU/RTFP.txt file.
  Or point your browser at (https://docs.google.com/document/d/1X0lThx8OK0ZgLMqVoXiR4ZrGURHrXK6NyLRbeXe3Xac/edit)
  or (https://docs.google.com/document/d/1GCdQC8SDbb54W1shjEXqGZ0Rq8a6kIeYutdSIajfpLA/edit?usp=sharing).