aboutsummaryrefslogtreecommitdiffstats
path: root/tools/testing/selftests/rcutorture/configs/rcu
diff options
context:
space:
mode:
authorPaul E. McKenney <paulmck@kernel.org>2020-04-10 13:47:41 -0700
committerPaul E. McKenney <paulmck@kernel.org>2020-04-27 11:02:50 -0700
commit6be7436d2245d3dd8b9a8f949367c13841c23308 (patch)
tree4fc01872f770ecda9bfb0ab085f205c573bdfdc3 /tools/testing/selftests/rcutorture/configs/rcu
parentrcu/tree: Count number of batched kfree_rcu() locklessly (diff)
downloadlinux-dev-6be7436d2245d3dd8b9a8f949367c13841c23308.tar.xz
linux-dev-6be7436d2245d3dd8b9a8f949367c13841c23308.zip
rcu: Add rcu_gp_might_be_stalled()
This commit adds rcu_gp_might_be_stalled(), which returns true if there is some reason to believe that the RCU grace period is stalled. The use case is where an RCU free-memory path needs to allocate memory in order to free it, a situation that should be avoided where possible. But where it is necessary, there is always the alternative of using synchronize_rcu() to wait for a grace period in order to avoid the allocation. And if the grace period is stalled, allocating memory to asynchronously wait for it is a bad idea of epic proportions: Far better to let others use the memory, because these others might actually be able to free that memory before the grace period ends. Thus, rcu_gp_might_be_stalled() can be used to help decide whether allocating memory on an RCU free path is a semi-reasonable course of action. Cc: Joel Fernandes <joel@joelfernandes.org> Cc: Uladzislau Rezki <urezki@gmail.com> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Diffstat (limited to 'tools/testing/selftests/rcutorture/configs/rcu')
0 files changed, 0 insertions, 0 deletions