diff options
author | Paul E. McKenney <paulmck@kernel.org> | 2023-12-13 18:49:20 +0100 |
---|---|---|
committer | Boqun Feng <boqun.feng@gmail.com> | 2024-02-14 16:53:50 +0100 |
commit | e15aed426a1bf5ba98e5a3989a7d41f2b2ee96d3 (patch) | |
tree | c387b5697f6ad694ddacbcf1ca1ac48798f71c98 /Documentation/RCU | |
parent | doc: Clarify use of slab constructors and SLAB_TYPESAFE_BY_RCU (diff) | |
download | linux-e15aed426a1bf5ba98e5a3989a7d41f2b2ee96d3.tar.xz linux-e15aed426a1bf5ba98e5a3989a7d41f2b2ee96d3.zip |
doc: Update checklist.rst discussion of callback execution
This commit completes the list of call_rcu*() functions that are not
guaranteed to have their callbacks executing on the same CPU. While in
the area, fix an unrelated typo.
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
Diffstat (limited to 'Documentation/RCU')
-rw-r--r-- | Documentation/RCU/checklist.rst | 21 |
1 files changed, 11 insertions, 10 deletions
diff --git a/Documentation/RCU/checklist.rst b/Documentation/RCU/checklist.rst index addd5c1547a4..3e6407de231c 100644 --- a/Documentation/RCU/checklist.rst +++ b/Documentation/RCU/checklist.rst @@ -383,16 +383,17 @@ over a rather long period of time, but improvements are always welcome! must use whatever locking or other synchronization is required to safely access and/or modify that data structure. - Do not assume that RCU callbacks will be executed on the same - CPU that executed the corresponding call_rcu() or call_srcu(). - For example, if a given CPU goes offline while having an RCU - callback pending, then that RCU callback will execute on some - surviving CPU. (If this was not the case, a self-spawning RCU - callback would prevent the victim CPU from ever going offline.) - Furthermore, CPUs designated by rcu_nocbs= might well *always* - have their RCU callbacks executed on some other CPUs, in fact, - for some real-time workloads, this is the whole point of using - the rcu_nocbs= kernel boot parameter. + Do not assume that RCU callbacks will be executed on + the same CPU that executed the corresponding call_rcu(), + call_srcu(), call_rcu_tasks(), call_rcu_tasks_rude(), or + call_rcu_tasks_trace(). For example, if a given CPU goes offline + while having an RCU callback pending, then that RCU callback + will execute on some surviving CPU. (If this was not the case, + a self-spawning RCU callback would prevent the victim CPU from + ever going offline.) Furthermore, CPUs designated by rcu_nocbs= + might well *always* have their RCU callbacks executed on some + other CPUs, in fact, for some real-time workloads, this is the + whole point of using the rcu_nocbs= kernel boot parameter. In addition, do not assume that callbacks queued in a given order will be invoked in that order, even if they all are queued on the |