Linux kernel mirror (for testing)
git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel
os
linux
doc: Update torture.rst
This commit updates torture.rst with wordsmithing and the addition of a
few more scripts.
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
+85
-4
+85
-4
Documentation/RCU/torture.rst
+85
-4
Documentation/RCU/torture.rst
···
206
206
using the --bootargs parameter discussed below.
207
207
208
208
Sometimes additional debugging is useful, and in such cases the --kconfig
209
-
parameter to kvm.sh may be used, for example, ``--kconfig 'CONFIG_KASAN=y'``.
209
+
parameter to kvm.sh may be used, for example, ``--kconfig 'CONFIG_RCU_EQS_DEBUG=y'``.
210
+
In addition, there are the --gdb, --kasan, and --kcsan parameters.
211
+
Note that --gdb limits you to one scenario per kvm.sh run and requires
212
+
that you have another window open from which to run ``gdb`` as instructed
213
+
by the script.
210
214
211
215
Kernel boot arguments can also be supplied, for example, to control
212
216
rcutorture's module parameters. For example, to test a change to RCU's
···
223
219
--bootargs 'rcutorture.fwd_progress=0'
224
220
225
221
Sometimes all that is needed is a full set of kernel builds. This is
226
-
what the --buildonly argument does.
222
+
what the --buildonly parameter does.
227
223
228
-
Finally, the --trust-make argument allows each kernel build to reuse what
229
-
it can from the previous kernel build.
224
+
The --duration parameter can override the default run time of 30 minutes.
225
+
For example, ``--duration 2d`` would run for two days, ``--duration 3h``
226
+
would run for three hours, ``--duration 5m`` would run for five minutes,
227
+
and ``--duration 45s`` would run for 45 seconds. This last can be useful
228
+
for tracking down rare boot-time failures.
229
+
230
+
Finally, the --trust-make parameter allows each kernel build to reuse what
231
+
it can from the previous kernel build. Please note that without the
232
+
--trust-make parameter, your tags files may be demolished.
230
233
231
234
There are additional more arcane arguments that are documented in the
232
235
source code of the kvm.sh script.
···
302
291
TREE07 ------- 167347 GPs (30.9902/s) [rcu: g1079021 f0x0 ] n_max_cbs: 478732
303
292
CPU count limited from 16 to 12
304
293
TREE09 ------- 752238 GPs (139.303/s) [rcu: g13075057 f0x0 ] n_max_cbs: 99011
294
+
295
+
296
+
Repeated Runs
297
+
=============
298
+
299
+
Suppose that you are chasing down a rare boot-time failure. Although you
300
+
could use kvm.sh, doing so will rebuild the kernel on each run. If you
301
+
need (say) 1,000 runs to have confidence that you have fixed the bug,
302
+
these pointless rebuilds can become extremely annoying.
303
+
304
+
This is why kvm-again.sh exists.
305
+
306
+
Suppose that a previous kvm.sh run left its output in this directory::
307
+
308
+
tools/testing/selftests/rcutorture/res/2022.11.03-11.26.28
309
+
310
+
Then this run can be re-run without rebuilding as follow:
311
+
312
+
kvm-again.sh tools/testing/selftests/rcutorture/res/2022.11.03-11.26.28
313
+
314
+
A few of the original run's kvm.sh parameters may be overridden, perhaps
315
+
most notably --duration and --bootargs. For example::
316
+
317
+
kvm-again.sh tools/testing/selftests/rcutorture/res/2022.11.03-11.26.28 \
318
+
--duration 45s
319
+
320
+
would re-run the previous test, but for only 45 seconds, thus facilitating
321
+
tracking down the aforementioned rare boot-time failure.
322
+
323
+
324
+
Distributed Runs
325
+
================
326
+
327
+
Although kvm.sh is quite useful, its testing is confined to a single
328
+
system. It is not all that hard to use your favorite framework to cause
329
+
(say) 5 instances of kvm.sh to run on your 5 systems, but this will very
330
+
likely unnecessarily rebuild kernels. In addition, manually distributing
331
+
the desired rcutorture scenarios across the available systems can be
332
+
painstaking and error-prone.
333
+
334
+
And this is why the kvm-remote.sh script exists.
335
+
336
+
If you the following command works::
337
+
338
+
ssh system0 date
339
+
340
+
and if it also works for system1, system2, system3, system4, and system5,
341
+
and all of these systems have 64 CPUs, you can type::
342
+
343
+
kvm-remote.sh "system0 system1 system2 system3 system4 system5" \
344
+
--cpus 64 --duration 8h --configs "5*CFLIST"
345
+
346
+
This will build each default scenario's kernel on the local system, then
347
+
spread each of five instances of each scenario over the systems listed,
348
+
running each scenario for eight hours. At the end of the runs, the
349
+
results will be gathered, recorded, and printed. Most of the parameters
350
+
that kvm.sh will accept can be passed to kvm-remote.sh, but the list of
351
+
systems must come first.
352
+
353
+
The kvm.sh ``--dryrun scenarios`` argument is useful for working out
354
+
how many scenarios may be run in one batch across a group of systems.
355
+
356
+
You can also re-run a previous remote run in a manner similar to kvm.sh:
357
+
358
+
kvm-remote.sh "system0 system1 system2 system3 system4 system5" \
359
+
tools/testing/selftests/rcutorture/res/2022.11.03-11.26.28-remote \
360
+
--duration 24h
361
+
362
+
In this case, most of the kvm-again.sh parmeters may be supplied following
363
+
the pathname of the old run-results directory.