Thomas Gleixner | ec8f24b | 2019-05-19 13:07:45 +0100 | [diff] [blame] | 1 | # SPDX-License-Identifier: GPL-2.0-only |
Paul E. McKenney | 43a0a2a | 2017-05-17 09:19:44 -0700 | [diff] [blame] | 2 | # |
| 3 | # RCU-related debugging configuration options |
| 4 | # |
| 5 | |
| 6 | menu "RCU Debugging" |
| 7 | |
| 8 | config PROVE_RCU |
| 9 | def_bool PROVE_LOCKING |
| 10 | |
Joel Fernandes (Google) | 2887594 | 2019-07-16 18:12:22 -0400 | [diff] [blame] | 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 | |
Paul E. McKenney | 43a0a2a | 2017-05-17 09:19:44 -0700 | [diff] [blame] | 22 | config TORTURE_TEST |
| 23 | tristate |
| 24 | default n |
| 25 | |
Paul E. McKenney | 4e88ec4 | 2020-08-11 21:18:12 -0700 | [diff] [blame] | 26 | config RCU_SCALE_TEST |
Paul E. McKenney | 43a0a2a | 2017-05-17 09:19:44 -0700 | [diff] [blame] | 27 | tristate "performance tests for RCU" |
| 28 | depends on DEBUG_KERNEL |
| 29 | select TORTURE_TEST |
| 30 | select SRCU |
| 31 | select TASKS_RCU |
Paul E. McKenney | 3d6e43c | 2020-03-03 15:02:50 -0800 | [diff] [blame] | 32 | select TASKS_RUDE_RCU |
Paul E. McKenney | c1a76c0 | 2020-03-10 10:32:30 -0700 | [diff] [blame] | 33 | select TASKS_TRACE_RCU |
Paul E. McKenney | 43a0a2a | 2017-05-17 09:19:44 -0700 | [diff] [blame] | 34 | default n |
| 35 | help |
| 36 | This option provides a kernel module that runs performance |
| 37 | tests on the RCU infrastructure. The kernel module may be built |
| 38 | after the fact on the running kernel to be tested, if desired. |
| 39 | |
| 40 | Say Y here if you want RCU performance tests to be built into |
| 41 | the kernel. |
| 42 | Say M if you want the RCU performance tests to build as a module. |
| 43 | Say N if you are unsure. |
| 44 | |
| 45 | config RCU_TORTURE_TEST |
| 46 | tristate "torture tests for RCU" |
| 47 | depends on DEBUG_KERNEL |
| 48 | select TORTURE_TEST |
| 49 | select SRCU |
| 50 | select TASKS_RCU |
Paul E. McKenney | 3d6e43c | 2020-03-03 15:02:50 -0800 | [diff] [blame] | 51 | select TASKS_RUDE_RCU |
Paul E. McKenney | c1a76c0 | 2020-03-10 10:32:30 -0700 | [diff] [blame] | 52 | select TASKS_TRACE_RCU |
Paul E. McKenney | 43a0a2a | 2017-05-17 09:19:44 -0700 | [diff] [blame] | 53 | default n |
| 54 | help |
| 55 | This option provides a kernel module that runs torture tests |
| 56 | on the RCU infrastructure. The kernel module may be built |
| 57 | after the fact on the running kernel to be tested, if desired. |
| 58 | |
| 59 | Say Y here if you want RCU torture tests to be built into |
| 60 | the kernel. |
| 61 | Say M if you want the RCU torture tests to build as a module. |
| 62 | Say N if you are unsure. |
| 63 | |
Paul E. McKenney | 8e4ec3d | 2020-06-17 11:33:54 -0700 | [diff] [blame] | 64 | config RCU_REF_SCALE_TEST |
| 65 | tristate "Scalability tests for read-side synchronization (RCU and others)" |
Joel Fernandes (Google) | 653ed64 | 2020-05-25 00:36:48 -0400 | [diff] [blame] | 66 | depends on DEBUG_KERNEL |
| 67 | select TORTURE_TEST |
| 68 | select SRCU |
| 69 | select TASKS_RCU |
| 70 | select TASKS_RUDE_RCU |
| 71 | select TASKS_TRACE_RCU |
| 72 | default n |
| 73 | help |
| 74 | This option provides a kernel module that runs performance tests |
| 75 | useful comparing RCU with various read-side synchronization mechanisms. |
| 76 | The kernel module may be built after the fact on the running kernel to be |
| 77 | tested, if desired. |
| 78 | |
| 79 | Say Y here if you want these performance tests built into the kernel. |
| 80 | Say M if you want to build it as a module instead. |
| 81 | Say N if you are unsure. |
| 82 | |
Paul E. McKenney | 43a0a2a | 2017-05-17 09:19:44 -0700 | [diff] [blame] | 83 | config RCU_CPU_STALL_TIMEOUT |
| 84 | int "RCU CPU stall timeout in seconds" |
| 85 | depends on RCU_STALL_COMMON |
| 86 | range 3 300 |
| 87 | default 21 |
| 88 | help |
| 89 | If a given RCU grace period extends more than the specified |
| 90 | number of seconds, a CPU stall warning is printed. If the |
| 91 | RCU grace period persists, additional CPU stall warnings are |
| 92 | printed at more widely spaced intervals. |
| 93 | |
| 94 | config RCU_TRACE |
| 95 | bool "Enable tracing for RCU" |
| 96 | depends on DEBUG_KERNEL |
| 97 | default y if TREE_RCU |
| 98 | select TRACE_CLOCK |
| 99 | help |
| 100 | This option enables additional tracepoints for ftrace-style |
| 101 | event tracing. |
| 102 | |
| 103 | Say Y here if you want to enable RCU tracing |
| 104 | Say N if you are unsure. |
| 105 | |
| 106 | config RCU_EQS_DEBUG |
| 107 | bool "Provide debugging asserts for adding NO_HZ support to an arch" |
| 108 | depends on DEBUG_KERNEL |
| 109 | help |
| 110 | This option provides consistency checks in RCU's handling of |
| 111 | NO_HZ. These checks have proven quite helpful in detecting |
| 112 | bugs in arch-specific NO_HZ code. |
| 113 | |
| 114 | Say N here if you need ultimate kernel/user switch latencies |
| 115 | Say Y if you are unsure |
| 116 | |
Paul E. McKenney | 8cbd0e3 | 2020-08-05 15:51:20 -0700 | [diff] [blame] | 117 | config RCU_STRICT_GRACE_PERIOD |
| 118 | bool "Provide debug RCU implementation with short grace periods" |
Paul E. McKenney | 4d80b8e | 2021-04-07 15:21:32 -0700 | [diff] [blame] | 119 | depends on DEBUG_KERNEL && RCU_EXPERT && NR_CPUS <= 4 |
Paul E. McKenney | 8cbd0e3 | 2020-08-05 15:51:20 -0700 | [diff] [blame] | 120 | default n |
| 121 | select PREEMPT_COUNT if PREEMPT=n |
| 122 | help |
| 123 | Select this option to build an RCU variant that is strict about |
| 124 | grace periods, making them as short as it can. This limits |
| 125 | scalability, destroys real-time response, degrades battery |
| 126 | lifetime and kills performance. Don't try this on large |
| 127 | machines, as in systems with more than about 10 or 20 CPUs. |
| 128 | But in conjunction with tools like KASAN, it can be helpful |
| 129 | when looking for certain types of RCU usage bugs, for example, |
| 130 | too-short RCU read-side critical sections. |
| 131 | |
Paul E. McKenney | 43a0a2a | 2017-05-17 09:19:44 -0700 | [diff] [blame] | 132 | endmenu # "RCU Debugging" |