Merge tag 'tags/bcm2835-dt-next-2019-03-04' into devicetree/fixes
[linux-2.6-block.git] / Documentation / locking / locktorture.txt
CommitLineData
cdf26bb1
DB
1Kernel Lock Torture Test Operation
2
3CONFIG_LOCK_TORTURE_TEST
4
5The CONFIG LOCK_TORTURE_TEST config option provides a kernel module
6that runs torture tests on core kernel locking primitives. The kernel
7module, 'locktorture', may be built after the fact on the running
8kernel to be tested, if desired. The tests periodically output status
9messages via printk(), which can be examined via the dmesg (perhaps
10grepping for "torture"). The test is started when the module is loaded,
11and stops when the module is unloaded. This program is based on how RCU
12is tortured, via rcutorture.
13
14This torture test consists of creating a number of kernel threads which
15acquire the lock and hold it for specific amount of time, thus simulating
16different critical region behaviors. The amount of contention on the lock
17can be simulated by either enlarging this critical region hold time and/or
18creating more kthreads.
19
20
21MODULE PARAMETERS
22
23This module has the following parameters:
24
25
26 ** Locktorture-specific **
27
28nwriters_stress Number of kernel threads that will stress exclusive lock
29 ownership (writers). The default value is twice the number
30 of online CPUs.
31
4f6332c1
DB
32nreaders_stress Number of kernel threads that will stress shared lock
33 ownership (readers). The default is the same amount of writer
34 locks. If the user did not specify nwriters_stress, then
35 both readers and writers be the amount of online CPUs.
36
cdf26bb1
DB
37torture_type Type of lock to torture. By default, only spinlocks will
38 be tortured. This module can torture the following locks,
39 with string values as follows:
40
41 o "lock_busted": Simulates a buggy lock implementation.
42
43 o "spin_lock": spin_lock() and spin_unlock() pairs.
44
45 o "spin_lock_irq": spin_lock_irq() and spin_unlock_irq()
46 pairs.
47
e34191fa
DB
48 o "rw_lock": read/write lock() and unlock() rwlock pairs.
49
50 o "rw_lock_irq": read/write lock_irq() and unlock_irq()
51 rwlock pairs.
52
42ddc75d
DB
53 o "mutex_lock": mutex_lock() and mutex_unlock() pairs.
54
095777c4
DB
55 o "rtmutex_lock": rtmutex_lock() and rtmutex_unlock()
56 pairs. Kernel must have CONFIG_RT_MUTEX=y.
57
4a3b427f
DB
58 o "rwsem_lock": read/write down() and up() semaphore pairs.
59
cdf26bb1
DB
60
61 ** Torture-framework (RCU + locking) **
62
63shutdown_secs The number of seconds to run the test before terminating
64 the test and powering off the system. The default is
65 zero, which disables test termination and system shutdown.
66 This capability is useful for automated testing.
67
68onoff_interval The number of seconds between each attempt to execute a
69 randomly selected CPU-hotplug operation. Defaults
70 to zero, which disables CPU hotplugging. In
71 CONFIG_HOTPLUG_CPU=n kernels, locktorture will silently
72 refuse to do any CPU-hotplug operations regardless of
73 what value is specified for onoff_interval.
74
75onoff_holdoff The number of seconds to wait until starting CPU-hotplug
76 operations. This would normally only be used when
77 locktorture was built into the kernel and started
78 automatically at boot time, in which case it is useful
79 in order to avoid confusing boot-time code with CPUs
80 coming and going. This parameter is only useful if
81 CONFIG_HOTPLUG_CPU is enabled.
82
83stat_interval Number of seconds between statistics-related printk()s.
84 By default, locktorture will report stats every 60 seconds.
85 Setting the interval to zero causes the statistics to
86 be printed -only- when the module is unloaded, and this
87 is the default.
88
89stutter The length of time to run the test before pausing for this
90 same period of time. Defaults to "stutter=5", so as
91 to run and pause for (roughly) five-second intervals.
92 Specifying "stutter=0" causes the test to run continuously
93 without pausing, which is the old default behavior.
94
95shuffle_interval The number of seconds to keep the test threads affinitied
96 to a particular subset of the CPUs, defaults to 3 seconds.
97 Used in conjunction with test_no_idle_hz.
98
99verbose Enable verbose debugging printing, via printk(). Enabled
100 by default. This extra information is mostly related to
101 high-level errors and reports from the main 'torture'
102 framework.
103
104
105STATISTICS
106
107Statistics are printed in the following format:
108
109spin_lock-torture: Writes: Total: 93746064 Max/Min: 0/0 Fail: 0
4f6332c1 110 (A) (B) (C) (D) (E)
cdf26bb1
DB
111
112(A): Lock type that is being tortured -- torture_type parameter.
113
4f6332c1
DB
114(B): Number of writer lock acquisitions. If dealing with a read/write primitive
115 a second "Reads" statistics line is printed.
116
117(C): Number of times the lock was acquired.
cdf26bb1 118
4f6332c1 119(D): Min and max number of times threads failed to acquire the lock.
cdf26bb1 120
4f6332c1 121(E): true/false values if there were errors acquiring the lock. This should
cdf26bb1
DB
122 -only- be positive if there is a bug in the locking primitive's
123 implementation. Otherwise a lock should never fail (i.e., spin_lock()).
124 Of course, the same applies for (C), above. A dummy example of this is
125 the "lock_busted" type.
126
127USAGE
128
129The following script may be used to torture locks:
130
131 #!/bin/sh
132
133 modprobe locktorture
134 sleep 3600
135 rmmod locktorture
136 dmesg | grep torture:
137
138The output can be manually inspected for the error flag of "!!!".
139One could of course create a more elaborate script that automatically
140checked for such errors. The "rmmod" command forces a "SUCCESS",
141"FAILURE", or "RCU_HOTPLUG" indication to be printk()ed. The first
142two are self-explanatory, while the last indicates that while there
143were no locking failures, CPU-hotplug problems were detected.
144
145Also see: Documentation/RCU/torture.txt