v2 RCU idle/no-CB changes for 3.9
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest0 of 14 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 14 patches the cover letter announces are in this archive.
Reviews trailers per patch
| Patch | Dietmar Eggemann |
|---|---|
| Series | T-b |
Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes.
Cover letter [PATCH tip/core/rcu 0/14] v2 RCU idle/no-CB changes for 3.9
Hello!
This series contains changes to RCU_FAST_NO_HZ idle entry/exit and also removes restrictions on no-CBs CPUs. This series contains some commits that are still a bit on experimental side, so you should avoid using these patches unless you would like to help debug them. ;-)
1. Remove restrictions on no-CBs CPUs. This patch is probably the
highest-risk of the group.
2. Allow some control of no-CBs CPUs at kernel-build time. The option
of most interest is probably the one that makes -all- CPUs be no-CBs CPUs.
3. Distinguish the no-CBs kthreads for the various RCU flavors.
Without this patch, CPU 0 would have up to three kthreads all named "rcuo0", which is less than optimal.
4. Export RCU_FAST_NO_HZ parameters to sysfs to allow run-time
adjustment.
5. Re-introduce callback acceleration during grace-period cleanup.
Now that the callbacks are associated with specific grace periods, such acceleration is idempotent, and it is now safe to accelerate more than needed. (In contrast, in the past, too-frequent callback acceleration resulted in infrequent RCU failures.)
6. Use the newly numbered callbacks to greatly reduce the CPU overhead
incurred at idle entry by RCU_FAST_NO_HZ. The fact that the callbacks are now numbered means that instead of repeatedly cranking the RCU state machine to try to get all callbacks invoked, we can instead rely on the numbering so that the CPU can take full advantage of any grace periods that elapse while it is asleep. CPUs with callbacks still have limited sleep times, especially if they have at least one non-lazy callback queued.
7-12. Allow CPUs to make known their need for future grace periods,
which is also used to reduce the need for frenetic RCU state-machine cranking upon RCU_FAST_NO_HZ entry to idle.
7. Move the release of the root rcu_node structure's ->lock
to then end of rcu_start_gp().
8. Repurpose no-CB's grace-period event tracing to that of
future grace periods, which share no-CB's grace-period mechanism.
9. Move the release of the root rcu_node structure's ->lock
to rcu_start_gp()'s callers.
10. Rename the rcu_node ->n_nocb_gp_requests field to
->need_future_gp.
11. Abstract rcu_start_future_gp() from rcu_nocb_wait_gp()
to that RCU_FAST_NO_HZ can use the no-CB CPUs mechanism for allowing a CPU to record its need for future grace periods.
12. Make rcu_accelerate_cbs() note the need for future
grace periods, thus avoiding delays in starting grace periods that currently happen due to the CPUs needing those grace periods being out of action when the previous grace period ends.
Changes since v1:
o Fixed a deadlock in #1 spotted by Xie ChanglongX.
o Updated #2 to bring the abbreviations in line with conventional
per-CPU kthread naming.
o Moved the first two patches into their own group.
Thanx, Paul
b/Documentation/kernel-parameters.txt | 7 b/include/linux/rcupdate.h | 1 b/include/trace/events/rcu.h | 71 ++ b/init/Kconfig | 52 +- b/kernel/rcutree.c | 277 ++++++++-- b/kernel/rcutree.h | 39 - b/kernel/rcutree_plugin.h | 865 ++++++++++++++-------------------- b/kernel/rcutree_trace.c | 2 8 files changed, 710 insertions(+), 604 deletions(-)