diff options
author | 2023-06-26 13:45:13 -0700 | |
---|---|---|
committer | 2023-07-14 15:00:12 -0700 | |
commit | db13710a0365ba66f8f232eb3bdfaa1a10d820f7 (patch) | |
tree | e858d9fb6006310748d04229fc4f9be7e8b22f89 /block/blk-cgroup.c | |
parent | rcu-tasks: Add kernel boot parameters for callback laziness (diff) | |
download | linux-db13710a0365ba66f8f232eb3bdfaa1a10d820f7.tar.gz linux-db13710a0365ba66f8f232eb3bdfaa1a10d820f7.tar.bz2 linux-db13710a0365ba66f8f232eb3bdfaa1a10d820f7.zip |
rcu-tasks: Cancel callback laziness if too many callbacks
The various RCU Tasks flavors now do lazy grace periods when there are
only asynchronous grace period requests. By default, the system will let
250 milliseconds elapse after the first call_rcu_tasks*() callbacki is
queued before starting a grace period. In contrast, synchronous grace
period requests such as synchronize_rcu_tasks*() will start a grace
period immediately.
However, invoking one of the call_rcu_tasks*() functions in a too-tight
loop can result in a callback flood, which in turn can exhaust memory
if grace periods are delayed for too long.
This commit therefore sets a limit so that the grace-period kthread
will be awakened when any CPU's callback list expands to contain
rcupdate.rcu_task_lazy_lim callbacks elements (defaulting to 32, set to -1
to disable), the grace-period kthread will be awakened, thus cancelling
any ongoing laziness and getting out in front of the potential callback
flood.
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Martin KaFai Lau <kafai@fb.com>
Cc: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Diffstat (limited to 'block/blk-cgroup.c')
0 files changed, 0 insertions, 0 deletions