perf/core: Fix narrow startup race when creating the perf nr_addr_filters sysfs file
[platform/kernel/linux-starfive.git] / kernel / rcu / Kconfig.debug
1 # SPDX-License-Identifier: GPL-2.0-only
2 #
3 # RCU-related debugging configuration options
4 #
5
6 menu "RCU Debugging"
7
8 config PROVE_RCU
9         def_bool PROVE_LOCKING
10
11 config PROVE_RCU_LIST
12         bool "RCU list lockdep debugging"
13         depends on PROVE_RCU && RCU_EXPERT
14         default n
15         help
16           Enable RCU lockdep checking for list usages. By default it is
17           turned off since there are several list RCU users that still
18           need to be converted to pass a lockdep expression. To prevent
19           false-positive splats, we keep it default disabled but once all
20           users are converted, we can remove this config option.
21
22 config TORTURE_TEST
23         tristate
24         default n
25
26 config RCU_SCALE_TEST
27         tristate "performance tests for RCU"
28         depends on DEBUG_KERNEL
29         select TORTURE_TEST
30         default n
31         help
32           This option provides a kernel module that runs performance
33           tests on the RCU infrastructure.  The kernel module may be built
34           after the fact on the running kernel to be tested, if desired.
35
36           Say Y here if you want RCU performance tests to be built into
37           the kernel.
38           Say M if you want the RCU performance tests to build as a module.
39           Say N if you are unsure.
40
41 config RCU_TORTURE_TEST
42         tristate "torture tests for RCU"
43         depends on DEBUG_KERNEL
44         select TORTURE_TEST
45         default n
46         help
47           This option provides a kernel module that runs torture tests
48           on the RCU infrastructure.  The kernel module may be built
49           after the fact on the running kernel to be tested, if desired.
50
51           Say Y here if you want RCU torture tests to be built into
52           the kernel.
53           Say M if you want the RCU torture tests to build as a module.
54           Say N if you are unsure.
55
56 config RCU_REF_SCALE_TEST
57         tristate "Scalability tests for read-side synchronization (RCU and others)"
58         depends on DEBUG_KERNEL
59         select TORTURE_TEST
60         default n
61         help
62           This option provides a kernel module that runs performance tests
63           useful comparing RCU with various read-side synchronization mechanisms.
64           The kernel module may be built after the fact on the running kernel to be
65           tested, if desired.
66
67           Say Y here if you want these performance tests built into the kernel.
68           Say M if you want to build it as a module instead.
69           Say N if you are unsure.
70
71 config RCU_CPU_STALL_TIMEOUT
72         int "RCU CPU stall timeout in seconds"
73         depends on RCU_STALL_COMMON
74         range 3 300
75         default 21
76         help
77           If a given RCU grace period extends more than the specified
78           number of seconds, a CPU stall warning is printed.  If the
79           RCU grace period persists, additional CPU stall warnings are
80           printed at more widely spaced intervals.
81
82 config RCU_EXP_CPU_STALL_TIMEOUT
83         int "Expedited RCU CPU stall timeout in milliseconds"
84         depends on RCU_STALL_COMMON
85         range 0 300000
86         default 0
87         help
88           If a given expedited RCU grace period extends more than the
89           specified number of milliseconds, a CPU stall warning is printed.
90           If the RCU grace period persists, additional CPU stall warnings
91           are printed at more widely spaced intervals.  A value of zero
92           says to use the RCU_CPU_STALL_TIMEOUT value converted from
93           seconds to milliseconds.
94
95 config RCU_CPU_STALL_CPUTIME
96         bool "Provide additional RCU stall debug information"
97         depends on RCU_STALL_COMMON
98         default n
99         help
100           Collect statistics during the sampling period, such as the number of
101           (hard interrupts, soft interrupts, task switches) and the cputime of
102           (hard interrupts, soft interrupts, kernel tasks) are added to the
103           RCU stall report. For multiple continuous RCU stalls, all sampling
104           periods begin at half of the first RCU stall timeout.
105           The boot option rcupdate.rcu_cpu_stall_cputime has the same function
106           as this one, but will override this if it exists.
107
108 config RCU_TRACE
109         bool "Enable tracing for RCU"
110         depends on DEBUG_KERNEL
111         default y if TREE_RCU
112         select TRACE_CLOCK
113         help
114           This option enables additional tracepoints for ftrace-style
115           event tracing.
116
117           Say Y here if you want to enable RCU tracing
118           Say N if you are unsure.
119
120 config RCU_EQS_DEBUG
121         bool "Provide debugging asserts for adding NO_HZ support to an arch"
122         depends on DEBUG_KERNEL
123         help
124           This option provides consistency checks in RCU's handling of
125           NO_HZ.  These checks have proven quite helpful in detecting
126           bugs in arch-specific NO_HZ code.
127
128           Say N here if you need ultimate kernel/user switch latencies
129           Say Y if you are unsure
130
131 config RCU_STRICT_GRACE_PERIOD
132         bool "Provide debug RCU implementation with short grace periods"
133         depends on DEBUG_KERNEL && RCU_EXPERT && NR_CPUS <= 4 && !TINY_RCU
134         default n
135         select PREEMPT_COUNT if PREEMPT=n
136         help
137           Select this option to build an RCU variant that is strict about
138           grace periods, making them as short as it can.  This limits
139           scalability, destroys real-time response, degrades battery
140           lifetime and kills performance.  Don't try this on large
141           machines, as in systems with more than about 10 or 20 CPUs.
142           But in conjunction with tools like KASAN, it can be helpful
143           when looking for certain types of RCU usage bugs, for example,
144           too-short RCU read-side critical sections.
145
146 endmenu # "RCU Debugging"