summaryrefslogtreecommitdiffstats
path: root/kernel/ucount.c
diff options
context:
space:
mode:
authorPaul E. McKenney <paulmck@kernel.org>2023-03-31 18:05:56 +0200
committerPaul E. McKenney <paulmck@kernel.org>2023-05-11 22:42:39 +0200
commitf51164a808b5bf1d81fc37eb53ab1eae59c79f2d (patch)
tree1db9fd2079380840d4b4eba6689e630783479357 /kernel/ucount.c
parentrcu: Check callback-invocation time limit for rcuc kthreads (diff)
downloadlinux-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