diff options
author | Paul E. McKenney <paulmck@kernel.org> | 2023-03-31 18:05:56 +0200 |
---|---|---|
committer | Paul E. McKenney <paulmck@kernel.org> | 2023-05-11 22:42:39 +0200 |
commit | f51164a808b5bf1d81fc37eb53ab1eae59c79f2d (patch) | |
tree | 1db9fd2079380840d4b4eba6689e630783479357 /kernel/ucount.c | |
parent | rcu: Check callback-invocation time limit for rcuc kthreads (diff) | |
download | linux-f51164a808b5bf1d81fc37eb53ab1eae59c79f2d.tar.xz linux-f51164a808b5bf1d81fc37eb53ab1eae59c79f2d.zip |
rcu: Employ jiffies-based backstop to callback time limit
Currently, if there are more than 100 ready-to-invoke RCU callbacks queued
on a given CPU, the rcu_do_batch() function sets a timeout for invocation
of the series. This timeout defaulting to three milliseconds, and may
be adjusted using the rcutree.rcu_resched_ns kernel boot parameter.
This timeout is checked using local_clock(), but the overhead of this
function combined with the common-case very small callback-invocation
overhead means that local_clock() is checked every 32nd invocation.
This works well except for longer-than average callbacks. For example,
a series of 500-microsecond-duration callbacks means that local_clock()
is checked only once every 16 milliseconds, which makes it difficult to
enforce a three-millisecond timeout.
This commit therefore adds a Kconfig option RCU_DOUBLE_CHECK_CB_TIME
that enables backup timeout checking using the coarser grained but
lighter weight jiffies. If the jiffies counter detects a timeout,
then local_clock() is consulted even if this is not the 32nd callback.
This prevents the aforementioned 16-millisecond latency blow.
Reported-by: Domas Mituzas <dmituzas@meta.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Diffstat (limited to 'kernel/ucount.c')
0 files changed, 0 insertions, 0 deletions