summaryrefslogtreecommitdiff
path: root/kernel/rcu/Kconfig
diff options
context:
space:
mode:
authorPaul E. McKenney <paulmck@kernel.org>2021-11-30 03:52:31 +0300
committerPaul E. McKenney <paulmck@kernel.org>2021-12-09 21:52:11 +0300
commitfd796e4139b481733a701c4d406056538f4c73cc (patch)
tree42818fc87d5831f104d553c35c1cad39183a5db3 /kernel/rcu/Kconfig
parent2cee0789b458afa384c422b5969c1a338891fd33 (diff)
downloadlinux-fd796e4139b481733a701c4d406056538f4c73cc.tar.xz
rcu-tasks: Use fewer callbacks queues if callback flood ends
By default, when lock contention is encountered, the RCU Tasks flavors of RCU switch to using per-CPU queueing. However, if the callback flood ends, per-CPU queueing continues to be used, which introduces significant additional overhead, especially for callback invocation, which fans out a series of workqueue handlers. This commit therefore switches back to single-queue operation if at the beginning of a grace period there are very few callbacks. The definition of "very few" is set by the rcupdate.rcu_task_collapse_lim module parameter, which defaults to 10. This switch happens in two phases, with the first phase causing future callbacks to be enqueued on CPU 0's queue, but with all queues continuing to be checked for grace periods and callback invocation. The second phase checks to see if an RCU grace period has elapsed and if all remaining RCU-Tasks callbacks are queued on CPU 0. If so, only CPU 0 is checked for future grace periods and callback operation. Of course, the return of contention anywhere during this process will result in returning to per-CPU callback queueing. Reported-by: Martin Lau <kafai@fb.com> Cc: Neeraj Upadhyay <neeraj.iitr10@gmail.com> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Diffstat (limited to 'kernel/rcu/Kconfig')
0 files changed, 0 insertions, 0 deletions