|author||Paul E. McKenney <firstname.lastname@example.org>||2011-01-07 02:33:47 -0800|
|committer||Paul E. McKenney <email@example.com>||2011-01-14 04:56:49 -0800|
rcu: demote SRCU_SYNCHRONIZE_DELAY from kernel-parameter status
Because the adaptive synchronize_srcu_expedited() approach has worked very well in testing, remove the kernel parameter and replace it by a C-preprocessor macro. If someone finds problems with this approach, a more complex and aggressively adaptive approach might be required. Longer term, SRCU will be merged with the other RCU implementations, at which point synchronize_srcu_expedited() will be event driven, just as synchronize_sched_expedited() currently is. At that point, there will be no need for this adaptive approach. Reported-by: Linus Torvalds <firstname.lastname@example.org> Signed-off-by: Paul E. McKenney <email@example.com>
Diffstat (limited to 'init')
1 files changed, 0 insertions, 15 deletions
diff --git a/init/Kconfig b/init/Kconfig
index 526ec1c7456a..e11bc793a91d 100644
@@ -497,21 +497,6 @@ config RCU_BOOST_DELAY
Accept the default if unsure.
- int "Microseconds to delay before waiting for readers"
- range 0 20
- default 10
- This option controls how long SRCU delays before entering its
- loop waiting on SRCU readers. The purpose of this loop is
- to avoid the unconditional context-switch penalty that would
- otherwise be incurred if there was an active SRCU reader,
- in a manner similar to adaptive locking schemes. This should
- be set to be a bit longer than the common-case SRCU read-side
- critical-section overhead.
- Accept the default if unsure.
endmenu # "RCU Subsystem"