diff options
author | Paul E. McKenney <paulmck@kernel.org> | 2019-10-30 19:56:10 +0100 |
---|---|---|
committer | Paul E. McKenney <paulmck@kernel.org> | 2020-02-21 01:00:20 +0100 |
commit | b2b00ddf193bf83dc561d965c67b18eb54ebcd83 (patch) | |
tree | 0cd4acf7fe8ab47afc17067de5bbde675a6d1dd3 /lib/decompress_unlzma.c | |
parent | rcu: Clear ->core_needs_qs at GP end or self-reported QS (diff) | |
download | linux-b2b00ddf193bf83dc561d965c67b18eb54ebcd83.tar.xz linux-b2b00ddf193bf83dc561d965c67b18eb54ebcd83.zip |
rcu: React to callback overload by aggressively seeking quiescent states
In default configutions, RCU currently waits at least 100 milliseconds
before asking cond_resched() and/or resched_rcu() for help seeking
quiescent states to end a grace period. But 100 milliseconds can be
one good long time during an RCU callback flood, for example, as can
happen when user processes repeatedly open and close files in a tight
loop. These 100-millisecond gaps in successive grace periods during a
callback flood can result in excessive numbers of callbacks piling up,
unnecessarily increasing memory footprint.
This commit therefore asks cond_resched() and/or resched_rcu() for help
as early as the first FQS scan when at least one of the CPUs has more
than 20,000 callbacks queued, a number that can be changed using the new
rcutree.qovld kernel boot parameter. An auxiliary qovld_calc variable
is used to avoid acquisition of locks that have not yet been initialized.
Early tests indicate that this reduces the RCU-callback memory footprint
during rcutorture floods by from 50% to 4x, depending on configuration.
Reported-by: Joel Fernandes (Google) <joel@joelfernandes.org>
Reported-by: Tejun Heo <tj@kernel.org>
[ paulmck: Fix bug located by Qian Cai. ]
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Tested-by: Dexuan Cui <decui@microsoft.com>
Tested-by: Qian Cai <cai@lca.pw>
Diffstat (limited to 'lib/decompress_unlzma.c')
0 files changed, 0 insertions, 0 deletions