2013-09-28 14:12:21 -07:00
|
|
|
#!/bin/bash
|
2019-02-11 07:14:09 -08:00
|
|
|
# SPDX-License-Identifier: GPL-2.0+
|
2013-09-28 14:12:21 -07:00
|
|
|
#
|
2017-12-11 08:20:25 -08:00
|
|
|
# Run a series of tests under KVM. By default, this series is specified
|
|
|
|
|
# by the relevant CFLIST file, but can be overridden by the --configs
|
|
|
|
|
# command-line argument.
|
2013-09-28 14:12:21 -07:00
|
|
|
#
|
2014-07-11 19:47:35 -04:00
|
|
|
# Usage: kvm.sh [ options ]
|
2013-09-28 14:12:21 -07:00
|
|
|
#
|
|
|
|
|
# Copyright (C) IBM Corporation, 2011
|
|
|
|
|
#
|
2019-02-11 07:14:09 -08:00
|
|
|
# Authors: Paul E. McKenney <paulmck@linux.ibm.com>
|
2013-09-28 14:12:21 -07:00
|
|
|
|
|
|
|
|
scriptname=$0
|
2013-09-30 14:49:43 -07:00
|
|
|
args="$*"
|
2013-09-28 14:12:21 -07:00
|
|
|
|
2017-08-30 15:33:49 -07:00
|
|
|
T=${TMPDIR-/tmp}/kvm.sh.$$
|
2014-01-15 15:48:41 -08:00
|
|
|
trap 'rm -rf $T' 0
|
|
|
|
|
mkdir $T
|
|
|
|
|
|
2017-11-03 19:17:24 +09:00
|
|
|
cd `dirname $scriptname`/../../../../../
|
|
|
|
|
|
2021-04-01 15:26:56 -07:00
|
|
|
# This script knows only English.
|
|
|
|
|
LANG=en_US.UTF-8; export LANG
|
|
|
|
|
|
2016-03-29 10:50:38 -07:00
|
|
|
dur=$((30*60))
|
2014-01-17 03:10:16 -08:00
|
|
|
dryrun=""
|
2022-01-25 21:08:55 -08:00
|
|
|
RCUTORTURE="`pwd`/tools/testing/selftests/rcutorture"; export RCUTORTURE
|
|
|
|
|
PATH=${RCUTORTURE}/bin:$PATH; export PATH
|
2019-11-25 14:33:28 -08:00
|
|
|
. functions.sh
|
|
|
|
|
|
|
|
|
|
TORTURE_ALLOTED_CPUS="`identify_qemu_vcpus`"
|
2014-02-26 14:28:43 -08:00
|
|
|
TORTURE_DEFCONFIG=defconfig
|
2014-03-06 14:44:46 -08:00
|
|
|
TORTURE_BOOT_IMAGE=""
|
torture: Provide bare-metal modprobe-based advice
In some environments, the torture-testing use of virtualization is
inconvenient. In such cases, the modprobe and rmmod commands may be used
to do torture testing, but significant setup is required to build, boot,
and modprobe a kernel so as to match a given torture-test scenario.
This commit therefore creates a "bare-metal" file in each results
directory containing steps to run the corresponding scenario using the
modprobe command on bare metal. For example, the contents of this file
after using kvm.sh to build an rcutorture TREE01 kernel, perhaps with
the --buildonly argument, is as follows:
To run this scenario on bare metal:
1. Set your bare-metal build tree to the state shown in this file:
/home/git/linux-rcu/tools/testing/selftests/rcutorture/res/2021.02.04-17.10.19/testid.txt
2. Update your bare-metal build tree's .config based on this file:
/home/git/linux-rcu/tools/testing/selftests/rcutorture/res/2021.02.04-17.10.19/TREE01/ConfigFragment
3. Make the bare-metal kernel's build system aware of your .config updates:
$ yes "" | make oldconfig
4. Build your bare-metal kernel.
5. Boot your bare-metal kernel with the following parameters:
maxcpus=8 nr_cpus=43 rcutree.gp_preinit_delay=3 rcutree.gp_init_delay=3 rcutree.gp_cleanup_delay=3 rcu_nocbs=0-1,3-7
6. Start the test with the following command:
$ modprobe rcutorture nocbs_nthreads=8 nocbs_toggle=1000 fwd_progress=0 onoff_interval=1000 onoff_holdoff=30 n_barrier_cbs=4 stat_interval=15 shutdown_secs=120 test_no_idle_hz=1 verbose=1
7. After some time, end the test with the following command:
$ rmmod rcutorture
8. Copy your bare-metal kernel's .config file, overwriting this file:
/home/git/linux-rcu/tools/testing/selftests/rcutorture/res/2021.02.04-17.10.19/TREE01/.config
9. Copy the console output from just before the modprobe to just after
the rmmod into this file:
/home/git/linux-rcu/tools/testing/selftests/rcutorture/res/2021.02.04-17.10.19/TREE01/console.log
10. Check for runtime errors using the following command:
$ tools/testing/selftests/rcutorture/bin/kvm-recheck.sh /home/git/linux-rcu/tools/testing/selftests/rcutorture/res/2021.02.04-17.10.19
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2021-02-03 15:44:29 -08:00
|
|
|
TORTURE_BUILDONLY=
|
2022-01-25 21:08:55 -08:00
|
|
|
TORTURE_INITRD="$RCUTORTURE/initrd"; export TORTURE_INITRD
|
2017-05-01 17:49:29 -07:00
|
|
|
TORTURE_KCONFIG_ARG=""
|
torture: Add gdb support
This commit adds a "--gdb" parameter to kvm.sh, which causes
"CONFIG_DEBUG_INFO=y" to be added to the Kconfig options, "nokaslr"
to be added to the boot parameters, and "-s -S" to be added to the qemu
arguments. Furthermore, the scripting prints messages telling the user
how to start up gdb for the run in question.
Because of the interactive nature of gdb sessions, only one "--configs"
scenario is permitted when "--gdb" is specified. For most torture types,
this means that a "--configs" argument is required, and that argument
must specify the single scenario of interest.
The usual cautions about breakpoints and timing apply, for example,
staring at your gdb prompt for too long will likely get you many
complaints, including RCU CPU stall warnings. Omar Sandoval further
suggests using gdb's "hbreak" command instead of the "break" command on
systems supporting hardware breakpoints, and further using the "commands"
option because the resulting non-interactive breakpoints are less likely
to get you RCU CPU stall warnings.
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2020-08-17 16:44:48 -07:00
|
|
|
TORTURE_KCONFIG_GDB_ARG=""
|
|
|
|
|
TORTURE_BOOT_GDB_ARG=""
|
|
|
|
|
TORTURE_QEMU_GDB_ARG=""
|
2021-02-16 15:32:23 -08:00
|
|
|
TORTURE_JITTER_START=""
|
|
|
|
|
TORTURE_JITTER_STOP=""
|
2020-04-09 17:14:18 -07:00
|
|
|
TORTURE_KCONFIG_KASAN_ARG=""
|
2020-04-07 17:31:35 -07:00
|
|
|
TORTURE_KCONFIG_KCSAN_ARG=""
|
2014-02-26 15:23:21 -08:00
|
|
|
TORTURE_KMAKE_ARG=""
|
2018-01-12 14:19:05 -08:00
|
|
|
TORTURE_QEMU_MEM=512
|
2022-03-27 10:06:53 -07:00
|
|
|
torture_qemu_mem_default=1
|
2021-04-27 13:51:35 -07:00
|
|
|
TORTURE_REMOTE=
|
2015-10-01 11:41:06 -07:00
|
|
|
TORTURE_SHUTDOWN_GRACE=180
|
2014-02-07 10:29:49 -08:00
|
|
|
TORTURE_SUITE=rcu
|
torture: Provide bare-metal modprobe-based advice
In some environments, the torture-testing use of virtualization is
inconvenient. In such cases, the modprobe and rmmod commands may be used
to do torture testing, but significant setup is required to build, boot,
and modprobe a kernel so as to match a given torture-test scenario.
This commit therefore creates a "bare-metal" file in each results
directory containing steps to run the corresponding scenario using the
modprobe command on bare metal. For example, the contents of this file
after using kvm.sh to build an rcutorture TREE01 kernel, perhaps with
the --buildonly argument, is as follows:
To run this scenario on bare metal:
1. Set your bare-metal build tree to the state shown in this file:
/home/git/linux-rcu/tools/testing/selftests/rcutorture/res/2021.02.04-17.10.19/testid.txt
2. Update your bare-metal build tree's .config based on this file:
/home/git/linux-rcu/tools/testing/selftests/rcutorture/res/2021.02.04-17.10.19/TREE01/ConfigFragment
3. Make the bare-metal kernel's build system aware of your .config updates:
$ yes "" | make oldconfig
4. Build your bare-metal kernel.
5. Boot your bare-metal kernel with the following parameters:
maxcpus=8 nr_cpus=43 rcutree.gp_preinit_delay=3 rcutree.gp_init_delay=3 rcutree.gp_cleanup_delay=3 rcu_nocbs=0-1,3-7
6. Start the test with the following command:
$ modprobe rcutorture nocbs_nthreads=8 nocbs_toggle=1000 fwd_progress=0 onoff_interval=1000 onoff_holdoff=30 n_barrier_cbs=4 stat_interval=15 shutdown_secs=120 test_no_idle_hz=1 verbose=1
7. After some time, end the test with the following command:
$ rmmod rcutorture
8. Copy your bare-metal kernel's .config file, overwriting this file:
/home/git/linux-rcu/tools/testing/selftests/rcutorture/res/2021.02.04-17.10.19/TREE01/.config
9. Copy the console output from just before the modprobe to just after
the rmmod into this file:
/home/git/linux-rcu/tools/testing/selftests/rcutorture/res/2021.02.04-17.10.19/TREE01/console.log
10. Check for runtime errors using the following command:
$ tools/testing/selftests/rcutorture/bin/kvm-recheck.sh /home/git/linux-rcu/tools/testing/selftests/rcutorture/res/2021.02.04-17.10.19
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2021-02-03 15:44:29 -08:00
|
|
|
TORTURE_MOD=rcutorture
|
2019-05-11 20:18:00 -07:00
|
|
|
TORTURE_TRUST_MAKE=""
|
2013-09-28 14:12:21 -07:00
|
|
|
resdir=""
|
2013-09-29 11:13:46 -07:00
|
|
|
configs=""
|
2014-01-15 15:48:41 -08:00
|
|
|
cpus=0
|
2019-12-02 13:24:07 -08:00
|
|
|
ds=`date +%Y.%m.%d-%H.%M.%S`
|
2016-06-01 13:09:19 -07:00
|
|
|
jitter="-1"
|
2013-09-28 14:12:21 -07:00
|
|
|
|
2020-11-22 09:55:34 -08:00
|
|
|
startdate="`date`"
|
|
|
|
|
starttime="`get_starttime`"
|
|
|
|
|
|
2013-09-28 14:12:21 -07:00
|
|
|
usage () {
|
|
|
|
|
echo "Usage: $scriptname optional arguments:"
|
2020-07-02 15:59:05 -07:00
|
|
|
echo " --allcpus"
|
2013-10-14 08:19:39 -07:00
|
|
|
echo " --bootargs kernel-boot-arguments"
|
2014-03-06 14:44:46 -08:00
|
|
|
echo " --bootimage relative-path-to-kernel-boot-image"
|
2013-10-10 14:52:07 -07:00
|
|
|
echo " --buildonly"
|
2015-05-11 13:55:47 -07:00
|
|
|
echo " --configs \"config-file list w/ repeat factor (3*TINY01)\""
|
2014-01-15 15:48:41 -08:00
|
|
|
echo " --cpus N"
|
2013-09-28 18:44:11 -07:00
|
|
|
echo " --datestamp string"
|
2014-02-26 14:28:43 -08:00
|
|
|
echo " --defconfig string"
|
2021-03-04 17:21:17 -08:00
|
|
|
echo " --dryrun batches|scenarios|sched|script"
|
2020-09-22 17:20:11 -07:00
|
|
|
echo " --duration minutes | <seconds>s | <hours>h | <days>d"
|
torture: Add gdb support
This commit adds a "--gdb" parameter to kvm.sh, which causes
"CONFIG_DEBUG_INFO=y" to be added to the Kconfig options, "nokaslr"
to be added to the boot parameters, and "-s -S" to be added to the qemu
arguments. Furthermore, the scripting prints messages telling the user
how to start up gdb for the run in question.
Because of the interactive nature of gdb sessions, only one "--configs"
scenario is permitted when "--gdb" is specified. For most torture types,
this means that a "--configs" argument is required, and that argument
must specify the single scenario of interest.
The usual cautions about breakpoints and timing apply, for example,
staring at your gdb prompt for too long will likely get you many
complaints, including RCU CPU stall warnings. Omar Sandoval further
suggests using gdb's "hbreak" command instead of the "break" command on
systems supporting hardware breakpoints, and further using the "commands"
option because the resulting non-interactive breakpoints are less likely
to get you RCU CPU stall warnings.
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2020-08-17 16:44:48 -07:00
|
|
|
echo " --gdb"
|
2020-07-19 12:17:53 -07:00
|
|
|
echo " --help"
|
2013-10-04 13:15:55 -07:00
|
|
|
echo " --interactive"
|
2016-03-29 14:22:26 -07:00
|
|
|
echo " --jitter N [ maxsleep (us) [ maxspin (us) ] ]"
|
2021-09-21 12:50:05 -07:00
|
|
|
echo " --kasan"
|
2017-05-01 17:49:29 -07:00
|
|
|
echo " --kconfig Kconfig-options"
|
2021-09-21 12:50:05 -07:00
|
|
|
echo " --kcsan"
|
2013-10-15 11:51:23 -07:00
|
|
|
echo " --kmake-arg kernel-make-arguments"
|
2013-10-04 13:15:55 -07:00
|
|
|
echo " --mac nn:nn:nn:nn:nn:nn"
|
2020-07-19 12:17:53 -07:00
|
|
|
echo " --memory megabytes|nnnG"
|
2013-10-15 10:42:25 -07:00
|
|
|
echo " --no-initrd"
|
2017-11-03 19:17:23 +09:00
|
|
|
echo " --qemu-args qemu-arguments"
|
2013-09-30 17:17:57 -07:00
|
|
|
echo " --qemu-cmd qemu-system-..."
|
2021-04-27 13:51:35 -07:00
|
|
|
echo " --remote"
|
2014-02-07 10:29:49 -08:00
|
|
|
echo " --results absolute-pathname"
|
2021-09-21 12:50:05 -07:00
|
|
|
echo " --shutdown-grace seconds"
|
2022-02-18 17:52:13 -08:00
|
|
|
echo " --torture lock|rcu|rcuscale|refscale|scf|X*"
|
2019-05-11 20:18:00 -07:00
|
|
|
echo " --trust-make"
|
2013-09-28 14:12:21 -07:00
|
|
|
exit 1
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
while test $# -gt 0
|
|
|
|
|
do
|
|
|
|
|
case "$1" in
|
2020-05-04 16:41:53 -07:00
|
|
|
--allcpus)
|
|
|
|
|
cpus=$TORTURE_ALLOTED_CPUS
|
|
|
|
|
max_cpus=$TORTURE_ALLOTED_CPUS
|
|
|
|
|
;;
|
2015-08-25 17:12:09 -07:00
|
|
|
--bootargs|--bootarg)
|
2013-10-14 08:19:39 -07:00
|
|
|
checkarg --bootargs "(list of kernel boot arguments)" "$#" "$2" '.*' '^--'
|
torture: Make kvm.sh arguments accumulate
Given that kvm.sh in invoked from scripts, it is only natural for
different levels of scripting to provide their own Kconfig option values,
for example. Unfortunately, right now, the last such argument on the
command line wins.
This commit therefore makes the --bootargs, --configs, --kconfigs,
--kmake-args, and --qemu-args argument values accumulate. For example,
where "--configs TREE01 --configs TREE02" would previously have run only
scenario TREE02, now it will run both scenarios.
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2020-11-20 20:09:55 -08:00
|
|
|
TORTURE_BOOTARGS="$TORTURE_BOOTARGS $2"
|
2013-10-14 08:19:39 -07:00
|
|
|
shift
|
|
|
|
|
;;
|
2014-03-06 14:44:46 -08:00
|
|
|
--bootimage)
|
|
|
|
|
checkarg --bootimage "(relative path to kernel boot image)" "$#" "$2" '[a-zA-Z0-9][a-zA-Z0-9_]*' '^--'
|
|
|
|
|
TORTURE_BOOT_IMAGE="$2"
|
|
|
|
|
shift
|
|
|
|
|
;;
|
2020-09-24 08:52:33 -07:00
|
|
|
--buildonly|--build-only)
|
2014-02-26 15:39:41 -08:00
|
|
|
TORTURE_BUILDONLY=1
|
2013-10-10 14:52:07 -07:00
|
|
|
;;
|
2015-08-25 17:12:09 -07:00
|
|
|
--configs|--config)
|
2021-02-17 07:15:41 -08:00
|
|
|
checkarg --configs "(list of config files)" "$#" "$2" '^[^/.a-z]\+$' '^--'
|
torture: Make kvm.sh arguments accumulate
Given that kvm.sh in invoked from scripts, it is only natural for
different levels of scripting to provide their own Kconfig option values,
for example. Unfortunately, right now, the last such argument on the
command line wins.
This commit therefore makes the --bootargs, --configs, --kconfigs,
--kmake-args, and --qemu-args argument values accumulate. For example,
where "--configs TREE01 --configs TREE02" would previously have run only
scenario TREE02, now it will run both scenarios.
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2020-11-20 20:09:55 -08:00
|
|
|
configs="$configs $2"
|
2013-09-28 14:12:21 -07:00
|
|
|
shift
|
|
|
|
|
;;
|
2014-01-15 15:48:41 -08:00
|
|
|
--cpus)
|
|
|
|
|
checkarg --cpus "(number)" "$#" "$2" '^[0-9]*$' '^--'
|
|
|
|
|
cpus=$2
|
2019-05-11 17:59:52 -07:00
|
|
|
TORTURE_ALLOTED_CPUS="$2"
|
2021-04-27 13:51:35 -07:00
|
|
|
if test -z "$TORTURE_REMOTE"
|
2019-11-25 14:33:28 -08:00
|
|
|
then
|
2021-04-27 13:51:35 -07:00
|
|
|
max_cpus="`identify_qemu_vcpus`"
|
|
|
|
|
if test "$TORTURE_ALLOTED_CPUS" -gt "$max_cpus"
|
|
|
|
|
then
|
|
|
|
|
TORTURE_ALLOTED_CPUS=$max_cpus
|
|
|
|
|
fi
|
2019-11-25 14:33:28 -08:00
|
|
|
fi
|
2014-01-15 15:48:41 -08:00
|
|
|
shift
|
|
|
|
|
;;
|
2013-09-28 18:44:11 -07:00
|
|
|
--datestamp)
|
2021-02-27 20:55:57 -08:00
|
|
|
checkarg --datestamp "(relative pathname)" "$#" "$2" '^[a-zA-Z0-9._/-]*$' '^--'
|
2013-09-28 18:44:11 -07:00
|
|
|
ds=$2
|
|
|
|
|
shift
|
|
|
|
|
;;
|
2014-02-26 14:28:43 -08:00
|
|
|
--defconfig)
|
|
|
|
|
checkarg --defconfig "defconfigtype" "$#" "$2" '^[^/][^/]*$' '^--'
|
|
|
|
|
TORTURE_DEFCONFIG=$2
|
|
|
|
|
shift
|
|
|
|
|
;;
|
2014-01-17 03:10:16 -08:00
|
|
|
--dryrun)
|
2021-03-04 17:21:17 -08:00
|
|
|
checkarg --dryrun "batches|sched|script" $# "$2" 'batches\|scenarios\|sched\|script' '^--'
|
2014-01-17 03:10:16 -08:00
|
|
|
dryrun=$2
|
|
|
|
|
shift
|
|
|
|
|
;;
|
2013-09-28 14:12:21 -07:00
|
|
|
--duration)
|
2020-09-22 17:20:11 -07:00
|
|
|
checkarg --duration "(minutes)" $# "$2" '^[0-9][0-9]*\(s\|m\|h\|d\|\)$' '^error'
|
|
|
|
|
mult=60
|
|
|
|
|
if echo "$2" | grep -q 's$'
|
|
|
|
|
then
|
|
|
|
|
mult=1
|
|
|
|
|
elif echo "$2" | grep -q 'h$'
|
|
|
|
|
then
|
|
|
|
|
mult=3600
|
|
|
|
|
elif echo "$2" | grep -q 'd$'
|
|
|
|
|
then
|
|
|
|
|
mult=86400
|
|
|
|
|
fi
|
|
|
|
|
ts=`echo $2 | sed -e 's/[smhd]$//'`
|
|
|
|
|
dur=$(($ts*mult))
|
2013-09-28 14:12:21 -07:00
|
|
|
shift
|
|
|
|
|
;;
|
torture: Add gdb support
This commit adds a "--gdb" parameter to kvm.sh, which causes
"CONFIG_DEBUG_INFO=y" to be added to the Kconfig options, "nokaslr"
to be added to the boot parameters, and "-s -S" to be added to the qemu
arguments. Furthermore, the scripting prints messages telling the user
how to start up gdb for the run in question.
Because of the interactive nature of gdb sessions, only one "--configs"
scenario is permitted when "--gdb" is specified. For most torture types,
this means that a "--configs" argument is required, and that argument
must specify the single scenario of interest.
The usual cautions about breakpoints and timing apply, for example,
staring at your gdb prompt for too long will likely get you many
complaints, including RCU CPU stall warnings. Omar Sandoval further
suggests using gdb's "hbreak" command instead of the "break" command on
systems supporting hardware breakpoints, and further using the "commands"
option because the resulting non-interactive breakpoints are less likely
to get you RCU CPU stall warnings.
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2020-08-17 16:44:48 -07:00
|
|
|
--gdb)
|
|
|
|
|
TORTURE_KCONFIG_GDB_ARG="CONFIG_DEBUG_INFO=y"; export TORTURE_KCONFIG_GDB_ARG
|
|
|
|
|
TORTURE_BOOT_GDB_ARG="nokaslr"; export TORTURE_BOOT_GDB_ARG
|
|
|
|
|
TORTURE_QEMU_GDB_ARG="-s -S"; export TORTURE_QEMU_GDB_ARG
|
|
|
|
|
;;
|
2020-07-19 12:17:53 -07:00
|
|
|
--help|-h)
|
|
|
|
|
usage
|
|
|
|
|
;;
|
2013-10-04 13:15:55 -07:00
|
|
|
--interactive)
|
2014-02-26 16:38:52 -08:00
|
|
|
TORTURE_QEMU_INTERACTIVE=1; export TORTURE_QEMU_INTERACTIVE
|
2013-10-04 13:15:55 -07:00
|
|
|
;;
|
2016-03-29 14:22:26 -07:00
|
|
|
--jitter)
|
|
|
|
|
checkarg --jitter "(# threads [ sleep [ spin ] ])" $# "$2" '^-\{,1\}[0-9]\+\( \+[0-9]\+\)\{,2\} *$' '^error$'
|
|
|
|
|
jitter="$2"
|
|
|
|
|
shift
|
|
|
|
|
;;
|
2021-09-21 12:50:05 -07:00
|
|
|
--kasan)
|
|
|
|
|
TORTURE_KCONFIG_KASAN_ARG="CONFIG_DEBUG_INFO=y CONFIG_KASAN=y"; export TORTURE_KCONFIG_KASAN_ARG
|
2022-03-27 10:06:53 -07:00
|
|
|
if test -n "$torture_qemu_mem_default"
|
|
|
|
|
then
|
|
|
|
|
TORTURE_QEMU_MEM=2G
|
|
|
|
|
fi
|
2021-09-21 12:50:05 -07:00
|
|
|
;;
|
2020-09-24 08:52:33 -07:00
|
|
|
--kconfig|--kconfigs)
|
2017-05-01 17:49:29 -07:00
|
|
|
checkarg --kconfig "(Kconfig options)" $# "$2" '^CONFIG_[A-Z0-9_]\+=\([ynm]\|[0-9]\+\)\( CONFIG_[A-Z0-9_]\+=\([ynm]\|[0-9]\+\)\)*$' '^error$'
|
torture: Make kvm.sh arguments accumulate
Given that kvm.sh in invoked from scripts, it is only natural for
different levels of scripting to provide their own Kconfig option values,
for example. Unfortunately, right now, the last such argument on the
command line wins.
This commit therefore makes the --bootargs, --configs, --kconfigs,
--kmake-args, and --qemu-args argument values accumulate. For example,
where "--configs TREE01 --configs TREE02" would previously have run only
scenario TREE02, now it will run both scenarios.
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2020-11-20 20:09:55 -08:00
|
|
|
TORTURE_KCONFIG_ARG="`echo "$TORTURE_KCONFIG_ARG $2" | sed -e 's/^ *//' -e 's/ *$//'`"
|
2017-05-01 17:49:29 -07:00
|
|
|
shift
|
|
|
|
|
;;
|
2020-04-07 17:31:35 -07:00
|
|
|
--kcsan)
|
2021-06-15 11:14:19 -07:00
|
|
|
TORTURE_KCONFIG_KCSAN_ARG="CONFIG_DEBUG_INFO=y CONFIG_KCSAN=y CONFIG_KCSAN_STRICT=y CONFIG_KCSAN_REPORT_ONCE_IN_MS=100000 CONFIG_KCSAN_VERBOSE=y CONFIG_DEBUG_LOCK_ALLOC=y CONFIG_PROVE_LOCKING=y"; export TORTURE_KCONFIG_KCSAN_ARG
|
2020-04-07 17:31:35 -07:00
|
|
|
;;
|
2020-09-24 08:52:33 -07:00
|
|
|
--kmake-arg|--kmake-args)
|
2013-10-15 11:51:23 -07:00
|
|
|
checkarg --kmake-arg "(kernel make arguments)" $# "$2" '.*' '^error$'
|
torture: Make kvm.sh arguments accumulate
Given that kvm.sh in invoked from scripts, it is only natural for
different levels of scripting to provide their own Kconfig option values,
for example. Unfortunately, right now, the last such argument on the
command line wins.
This commit therefore makes the --bootargs, --configs, --kconfigs,
--kmake-args, and --qemu-args argument values accumulate. For example,
where "--configs TREE01 --configs TREE02" would previously have run only
scenario TREE02, now it will run both scenarios.
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2020-11-20 20:09:55 -08:00
|
|
|
TORTURE_KMAKE_ARG="`echo "$TORTURE_KMAKE_ARG $2" | sed -e 's/^ *//' -e 's/ *$//'`"
|
2013-10-15 11:51:23 -07:00
|
|
|
shift
|
|
|
|
|
;;
|
2013-10-04 13:15:55 -07:00
|
|
|
--mac)
|
|
|
|
|
checkarg --mac "(MAC address)" $# "$2" '^\([0-9a-fA-F]\{2\}:\)\{5\}[0-9a-fA-F]\{2\}$' error
|
2014-02-26 16:41:18 -08:00
|
|
|
TORTURE_QEMU_MAC=$2
|
2013-10-04 13:15:55 -07:00
|
|
|
shift
|
|
|
|
|
;;
|
2018-01-12 14:19:05 -08:00
|
|
|
--memory)
|
|
|
|
|
checkarg --memory "(memory size)" $# "$2" '^[0-9]\+[MG]\?$' error
|
|
|
|
|
TORTURE_QEMU_MEM=$2
|
2022-03-27 10:06:53 -07:00
|
|
|
torture_qemu_mem_default=
|
2018-01-12 14:19:05 -08:00
|
|
|
shift
|
|
|
|
|
;;
|
2013-10-15 10:42:25 -07:00
|
|
|
--no-initrd)
|
2014-02-26 11:16:07 -08:00
|
|
|
TORTURE_INITRD=""; export TORTURE_INITRD
|
2013-10-15 10:42:25 -07:00
|
|
|
;;
|
2015-08-25 17:12:09 -07:00
|
|
|
--qemu-args|--qemu-arg)
|
2017-11-03 19:17:23 +09:00
|
|
|
checkarg --qemu-args "(qemu arguments)" $# "$2" '^-' '^error'
|
torture: Make kvm.sh arguments accumulate
Given that kvm.sh in invoked from scripts, it is only natural for
different levels of scripting to provide their own Kconfig option values,
for example. Unfortunately, right now, the last such argument on the
command line wins.
This commit therefore makes the --bootargs, --configs, --kconfigs,
--kmake-args, and --qemu-args argument values accumulate. For example,
where "--configs TREE01 --configs TREE02" would previously have run only
scenario TREE02, now it will run both scenarios.
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2020-11-20 20:09:55 -08:00
|
|
|
TORTURE_QEMU_ARG="`echo "$TORTURE_QEMU_ARG $2" | sed -e 's/^ *//' -e 's/ *$//'`"
|
2013-10-15 09:22:48 -07:00
|
|
|
shift
|
|
|
|
|
;;
|
2013-09-30 17:17:57 -07:00
|
|
|
--qemu-cmd)
|
|
|
|
|
checkarg --qemu-cmd "(qemu-system-...)" $# "$2" 'qemu-system-' '^--'
|
2014-02-26 16:44:26 -08:00
|
|
|
TORTURE_QEMU_CMD="$2"
|
2013-09-30 17:17:57 -07:00
|
|
|
shift
|
|
|
|
|
;;
|
2021-04-27 13:51:35 -07:00
|
|
|
--remote)
|
|
|
|
|
TORTURE_REMOTE=1
|
|
|
|
|
;;
|
2013-09-28 14:12:21 -07:00
|
|
|
--results)
|
2013-10-15 09:22:48 -07:00
|
|
|
checkarg --results "(absolute pathname)" "$#" "$2" '^/' '^error'
|
2013-09-28 14:12:21 -07:00
|
|
|
resdir=$2
|
|
|
|
|
shift
|
|
|
|
|
;;
|
2015-10-01 11:41:06 -07:00
|
|
|
--shutdown-grace)
|
|
|
|
|
checkarg --shutdown-grace "(seconds)" "$#" "$2" '^[0-9]*$' '^error'
|
|
|
|
|
TORTURE_SHUTDOWN_GRACE=$2
|
|
|
|
|
shift
|
|
|
|
|
;;
|
2014-02-07 10:29:49 -08:00
|
|
|
--torture)
|
2022-02-18 17:52:13 -08:00
|
|
|
checkarg --torture "(suite name)" "$#" "$2" '^\(lock\|rcu\|rcuscale\|refscale\|scf\|X.*\)$' '^--'
|
2014-02-07 10:29:49 -08:00
|
|
|
TORTURE_SUITE=$2
|
torture: Provide bare-metal modprobe-based advice
In some environments, the torture-testing use of virtualization is
inconvenient. In such cases, the modprobe and rmmod commands may be used
to do torture testing, but significant setup is required to build, boot,
and modprobe a kernel so as to match a given torture-test scenario.
This commit therefore creates a "bare-metal" file in each results
directory containing steps to run the corresponding scenario using the
modprobe command on bare metal. For example, the contents of this file
after using kvm.sh to build an rcutorture TREE01 kernel, perhaps with
the --buildonly argument, is as follows:
To run this scenario on bare metal:
1. Set your bare-metal build tree to the state shown in this file:
/home/git/linux-rcu/tools/testing/selftests/rcutorture/res/2021.02.04-17.10.19/testid.txt
2. Update your bare-metal build tree's .config based on this file:
/home/git/linux-rcu/tools/testing/selftests/rcutorture/res/2021.02.04-17.10.19/TREE01/ConfigFragment
3. Make the bare-metal kernel's build system aware of your .config updates:
$ yes "" | make oldconfig
4. Build your bare-metal kernel.
5. Boot your bare-metal kernel with the following parameters:
maxcpus=8 nr_cpus=43 rcutree.gp_preinit_delay=3 rcutree.gp_init_delay=3 rcutree.gp_cleanup_delay=3 rcu_nocbs=0-1,3-7
6. Start the test with the following command:
$ modprobe rcutorture nocbs_nthreads=8 nocbs_toggle=1000 fwd_progress=0 onoff_interval=1000 onoff_holdoff=30 n_barrier_cbs=4 stat_interval=15 shutdown_secs=120 test_no_idle_hz=1 verbose=1
7. After some time, end the test with the following command:
$ rmmod rcutorture
8. Copy your bare-metal kernel's .config file, overwriting this file:
/home/git/linux-rcu/tools/testing/selftests/rcutorture/res/2021.02.04-17.10.19/TREE01/.config
9. Copy the console output from just before the modprobe to just after
the rmmod into this file:
/home/git/linux-rcu/tools/testing/selftests/rcutorture/res/2021.02.04-17.10.19/TREE01/console.log
10. Check for runtime errors using the following command:
$ tools/testing/selftests/rcutorture/bin/kvm-recheck.sh /home/git/linux-rcu/tools/testing/selftests/rcutorture/res/2021.02.04-17.10.19
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2021-02-03 15:44:29 -08:00
|
|
|
TORTURE_MOD="`echo $TORTURE_SUITE | sed -e 's/^\(lock\|rcu\|scf\)$/\1torture/'`"
|
2014-02-07 10:29:49 -08:00
|
|
|
shift
|
2020-08-11 21:18:12 -07:00
|
|
|
if test "$TORTURE_SUITE" = rcuscale || test "$TORTURE_SUITE" = refscale
|
2018-01-30 19:36:38 -08:00
|
|
|
then
|
2020-06-17 12:06:47 -07:00
|
|
|
# If you really want jitter for refscale or
|
2020-08-11 21:18:12 -07:00
|
|
|
# rcuscale, specify it after specifying the rcuscale
|
2020-06-17 12:06:47 -07:00
|
|
|
# or the refscale. (But why jitter in these cases?)
|
2018-01-30 19:36:38 -08:00
|
|
|
jitter=0
|
|
|
|
|
fi
|
2014-02-07 10:29:49 -08:00
|
|
|
;;
|
2019-05-11 20:18:00 -07:00
|
|
|
--trust-make)
|
|
|
|
|
TORTURE_TRUST_MAKE="y"
|
|
|
|
|
;;
|
2013-09-28 14:12:21 -07:00
|
|
|
*)
|
2013-10-01 10:14:09 -07:00
|
|
|
echo Unknown argument $1
|
2013-09-28 14:12:21 -07:00
|
|
|
usage
|
|
|
|
|
;;
|
|
|
|
|
esac
|
|
|
|
|
shift
|
|
|
|
|
done
|
|
|
|
|
|
2020-12-11 16:26:50 -08:00
|
|
|
if test -n "$dryrun" || test -z "$TORTURE_INITRD" || tools/testing/selftests/rcutorture/bin/mkinitrd.sh
|
2018-08-22 14:16:46 -07:00
|
|
|
then
|
|
|
|
|
:
|
|
|
|
|
else
|
|
|
|
|
echo No initrd and unable to create one, aborting test >&2
|
|
|
|
|
exit 1
|
|
|
|
|
fi
|
|
|
|
|
|
2022-01-25 21:08:55 -08:00
|
|
|
CONFIGFRAG=${RCUTORTURE}/configs/${TORTURE_SUITE}; export CONFIGFRAG
|
2013-09-29 11:13:46 -07:00
|
|
|
|
torture: Allow "CFLIST" to specify default list of scenarios
On a large system, it can be convenient to tell rcutorture to run
several instances of the default scenarios. Currently, this requires
explicitly listing them, for example, "--configs '2*SRCU-N 2*SRCU-P...'".
Although this works, it is rather inconvenient.
This commit therefore allows "CFLIST" to be specified to indicate the
default list of scenarios called out in the relevant CFLIST file, for
example, for RCU, tools/testing/selftests/rcutorture/configs/rcu/CFLIST.
In addition, multipliers may be used to run multiple instances of all
the scenarios. For example, on a 256-CPU system, "--configs '3*CFLIST'"
would run three instances of each scenario concurrently with one CPU
left over. Thus "--configs '3*CFLIST TINY01'" would exactly consume all
256 CPUs, which makes rcutorture's jitter feature more effective.
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2019-11-22 06:14:21 -08:00
|
|
|
defaultconfigs="`tr '\012' ' ' < $CONFIGFRAG/CFLIST`"
|
2013-09-29 11:13:46 -07:00
|
|
|
if test -z "$configs"
|
|
|
|
|
then
|
torture: Allow "CFLIST" to specify default list of scenarios
On a large system, it can be convenient to tell rcutorture to run
several instances of the default scenarios. Currently, this requires
explicitly listing them, for example, "--configs '2*SRCU-N 2*SRCU-P...'".
Although this works, it is rather inconvenient.
This commit therefore allows "CFLIST" to be specified to indicate the
default list of scenarios called out in the relevant CFLIST file, for
example, for RCU, tools/testing/selftests/rcutorture/configs/rcu/CFLIST.
In addition, multipliers may be used to run multiple instances of all
the scenarios. For example, on a 256-CPU system, "--configs '3*CFLIST'"
would run three instances of each scenario concurrently with one CPU
left over. Thus "--configs '3*CFLIST TINY01'" would exactly consume all
256 CPUs, which makes rcutorture's jitter feature more effective.
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2019-11-22 06:14:21 -08:00
|
|
|
configs=$defaultconfigs
|
2013-09-29 11:13:46 -07:00
|
|
|
fi
|
2013-09-28 14:12:21 -07:00
|
|
|
|
|
|
|
|
if test -z "$resdir"
|
|
|
|
|
then
|
2022-01-25 21:08:55 -08:00
|
|
|
resdir=$RCUTORTURE/res
|
2014-01-27 12:31:20 -08:00
|
|
|
fi
|
|
|
|
|
|
2014-01-17 21:56:57 -08:00
|
|
|
# Create a file of test-name/#cpus pairs, sorted by decreasing #cpus.
|
torture: Allow "CFLIST" to specify default list of scenarios
On a large system, it can be convenient to tell rcutorture to run
several instances of the default scenarios. Currently, this requires
explicitly listing them, for example, "--configs '2*SRCU-N 2*SRCU-P...'".
Although this works, it is rather inconvenient.
This commit therefore allows "CFLIST" to be specified to indicate the
default list of scenarios called out in the relevant CFLIST file, for
example, for RCU, tools/testing/selftests/rcutorture/configs/rcu/CFLIST.
In addition, multipliers may be used to run multiple instances of all
the scenarios. For example, on a 256-CPU system, "--configs '3*CFLIST'"
would run three instances of each scenario concurrently with one CPU
left over. Thus "--configs '3*CFLIST TINY01'" would exactly consume all
256 CPUs, which makes rcutorture's jitter feature more effective.
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2019-11-22 06:14:21 -08:00
|
|
|
configs_derep=
|
2013-09-28 14:12:21 -07:00
|
|
|
for CF in $configs
|
|
|
|
|
do
|
2015-05-11 13:55:47 -07:00
|
|
|
case $CF in
|
2021-12-02 11:24:05 -08:00
|
|
|
[0-9]\**|[0-9][0-9]\**|[0-9][0-9][0-9]\**|[0-9][0-9][0-9][0-9]\**)
|
2015-05-11 13:55:47 -07:00
|
|
|
config_reps=`echo $CF | sed -e 's/\*.*$//'`
|
|
|
|
|
CF1=`echo $CF | sed -e 's/^[^*]*\*//'`
|
|
|
|
|
;;
|
|
|
|
|
*)
|
|
|
|
|
config_reps=1
|
|
|
|
|
CF1=$CF
|
|
|
|
|
;;
|
|
|
|
|
esac
|
torture: Allow "CFLIST" to specify default list of scenarios
On a large system, it can be convenient to tell rcutorture to run
several instances of the default scenarios. Currently, this requires
explicitly listing them, for example, "--configs '2*SRCU-N 2*SRCU-P...'".
Although this works, it is rather inconvenient.
This commit therefore allows "CFLIST" to be specified to indicate the
default list of scenarios called out in the relevant CFLIST file, for
example, for RCU, tools/testing/selftests/rcutorture/configs/rcu/CFLIST.
In addition, multipliers may be used to run multiple instances of all
the scenarios. For example, on a 256-CPU system, "--configs '3*CFLIST'"
would run three instances of each scenario concurrently with one CPU
left over. Thus "--configs '3*CFLIST TINY01'" would exactly consume all
256 CPUs, which makes rcutorture's jitter feature more effective.
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2019-11-22 06:14:21 -08:00
|
|
|
for ((cur_rep=0;cur_rep<$config_reps;cur_rep++))
|
|
|
|
|
do
|
|
|
|
|
configs_derep="$configs_derep $CF1"
|
|
|
|
|
done
|
|
|
|
|
done
|
|
|
|
|
touch $T/cfgcpu
|
|
|
|
|
configs_derep="`echo $configs_derep | sed -e "s/\<CFLIST\>/$defaultconfigs/g"`"
|
torture: Add gdb support
This commit adds a "--gdb" parameter to kvm.sh, which causes
"CONFIG_DEBUG_INFO=y" to be added to the Kconfig options, "nokaslr"
to be added to the boot parameters, and "-s -S" to be added to the qemu
arguments. Furthermore, the scripting prints messages telling the user
how to start up gdb for the run in question.
Because of the interactive nature of gdb sessions, only one "--configs"
scenario is permitted when "--gdb" is specified. For most torture types,
this means that a "--configs" argument is required, and that argument
must specify the single scenario of interest.
The usual cautions about breakpoints and timing apply, for example,
staring at your gdb prompt for too long will likely get you many
complaints, including RCU CPU stall warnings. Omar Sandoval further
suggests using gdb's "hbreak" command instead of the "break" command on
systems supporting hardware breakpoints, and further using the "commands"
option because the resulting non-interactive breakpoints are less likely
to get you RCU CPU stall warnings.
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2020-08-17 16:44:48 -07:00
|
|
|
if test -n "$TORTURE_KCONFIG_GDB_ARG"
|
|
|
|
|
then
|
|
|
|
|
if test "`echo $configs_derep | wc -w`" -gt 1
|
|
|
|
|
then
|
|
|
|
|
echo "The --config list is: $configs_derep."
|
|
|
|
|
echo "Only one --config permitted with --gdb, terminating."
|
|
|
|
|
exit 1
|
|
|
|
|
fi
|
|
|
|
|
fi
|
2020-12-24 15:28:14 -08:00
|
|
|
echo 'BEGIN {' > $T/cfgcpu.awk
|
|
|
|
|
for CF1 in `echo $configs_derep | tr -s ' ' '\012' | sort -u`
|
torture: Allow "CFLIST" to specify default list of scenarios
On a large system, it can be convenient to tell rcutorture to run
several instances of the default scenarios. Currently, this requires
explicitly listing them, for example, "--configs '2*SRCU-N 2*SRCU-P...'".
Although this works, it is rather inconvenient.
This commit therefore allows "CFLIST" to be specified to indicate the
default list of scenarios called out in the relevant CFLIST file, for
example, for RCU, tools/testing/selftests/rcutorture/configs/rcu/CFLIST.
In addition, multipliers may be used to run multiple instances of all
the scenarios. For example, on a 256-CPU system, "--configs '3*CFLIST'"
would run three instances of each scenario concurrently with one CPU
left over. Thus "--configs '3*CFLIST TINY01'" would exactly consume all
256 CPUs, which makes rcutorture's jitter feature more effective.
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2019-11-22 06:14:21 -08:00
|
|
|
do
|
2015-05-11 13:55:47 -07:00
|
|
|
if test -f "$CONFIGFRAG/$CF1"
|
2013-10-19 06:28:21 -07:00
|
|
|
then
|
2020-11-24 13:12:13 -08:00
|
|
|
if echo "$TORTURE_KCONFIG_ARG" | grep -q '\<CONFIG_NR_CPUS='
|
|
|
|
|
then
|
|
|
|
|
echo "$TORTURE_KCONFIG_ARG" | tr -s ' ' | tr ' ' '\012' > $T/KCONFIG_ARG
|
|
|
|
|
cpu_count=`configNR_CPUS.sh $T/KCONFIG_ARG`
|
|
|
|
|
else
|
|
|
|
|
cpu_count=`configNR_CPUS.sh $CONFIGFRAG/$CF1`
|
|
|
|
|
fi
|
2015-05-11 13:55:47 -07:00
|
|
|
cpu_count=`configfrag_boot_cpus "$TORTURE_BOOTARGS" "$CONFIGFRAG/$CF1" "$cpu_count"`
|
2017-06-09 14:09:21 -07:00
|
|
|
cpu_count=`configfrag_boot_maxcpus "$TORTURE_BOOTARGS" "$CONFIGFRAG/$CF1" "$cpu_count"`
|
2020-12-24 15:28:14 -08:00
|
|
|
echo 'scenariocpu["'"$CF1"'"] = '"$cpu_count"';' >> $T/cfgcpu.awk
|
2014-01-15 15:48:41 -08:00
|
|
|
else
|
2015-05-11 13:55:47 -07:00
|
|
|
echo "The --configs file $CF1 does not exist, terminating."
|
2014-01-15 15:48:41 -08:00
|
|
|
exit 1
|
2013-10-19 06:28:21 -07:00
|
|
|
fi
|
2013-09-28 14:12:21 -07:00
|
|
|
done
|
2020-12-24 15:28:14 -08:00
|
|
|
cat << '___EOF___' >> $T/cfgcpu.awk
|
|
|
|
|
}
|
|
|
|
|
{
|
|
|
|
|
for (i = 1; i <= NF; i++)
|
|
|
|
|
print $i, scenariocpu[$i];
|
|
|
|
|
}
|
|
|
|
|
___EOF___
|
|
|
|
|
echo $configs_derep | awk -f $T/cfgcpu.awk > $T/cfgcpu
|
2017-08-30 15:33:49 -07:00
|
|
|
sort -k2nr $T/cfgcpu -T="$T" > $T/cfgcpu.sort
|
2014-01-15 15:48:41 -08:00
|
|
|
|
2014-01-17 21:56:57 -08:00
|
|
|
# Use a greedy bin-packing algorithm, sorting the list accordingly.
|
2014-01-17 14:18:05 -08:00
|
|
|
awk < $T/cfgcpu.sort > $T/cfgcpu.pack -v ncpus=$cpus '
|
|
|
|
|
BEGIN {
|
|
|
|
|
njobs = 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
{
|
2014-01-17 21:56:57 -08:00
|
|
|
# Read file of tests and corresponding required numbers of CPUs.
|
2014-01-17 14:18:05 -08:00
|
|
|
cf[njobs] = $1;
|
|
|
|
|
cpus[njobs] = $2;
|
|
|
|
|
njobs++;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
END {
|
|
|
|
|
batch = 0;
|
|
|
|
|
nc = -1;
|
2014-01-17 21:56:57 -08:00
|
|
|
|
2020-12-24 15:28:14 -08:00
|
|
|
# Each pass through the following loop creates on test batch that
|
|
|
|
|
# can be executed concurrently given ncpus. Note that a given test
|
|
|
|
|
# that requires more than the available CPUs will run in its own
|
|
|
|
|
# batch. Such tests just have to make do with what is available.
|
2014-01-17 14:18:05 -08:00
|
|
|
while (nc != ncpus) {
|
|
|
|
|
batch++;
|
|
|
|
|
nc = ncpus;
|
2014-01-17 21:56:57 -08:00
|
|
|
|
|
|
|
|
# Each pass through the following loop considers one
|
|
|
|
|
# test for inclusion in the current batch.
|
2014-01-17 14:18:05 -08:00
|
|
|
for (i = 0; i < njobs; i++) {
|
|
|
|
|
if (done[i])
|
2014-01-17 21:56:57 -08:00
|
|
|
continue; # Already part of a batch.
|
2014-01-17 14:18:05 -08:00
|
|
|
if (nc >= cpus[i] || nc == ncpus) {
|
2014-01-17 21:56:57 -08:00
|
|
|
|
|
|
|
|
# This test fits into the current batch.
|
2014-01-17 14:18:05 -08:00
|
|
|
done[i] = batch;
|
|
|
|
|
nc -= cpus[i];
|
|
|
|
|
if (nc <= 0)
|
2014-01-17 21:56:57 -08:00
|
|
|
break; # Too-big test in its own batch.
|
2014-01-17 14:18:05 -08:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
2014-01-17 21:56:57 -08:00
|
|
|
|
|
|
|
|
# Dump out the tests in batch order.
|
2014-01-17 14:18:05 -08:00
|
|
|
for (b = 1; b <= batch; b++)
|
|
|
|
|
for (i = 0; i < njobs; i++)
|
|
|
|
|
if (done[i] == b)
|
|
|
|
|
print cf[i], cpus[i];
|
|
|
|
|
}'
|
|
|
|
|
|
2014-01-17 21:56:57 -08:00
|
|
|
# Generate a script to execute the tests in appropriate batches.
|
2014-02-07 10:29:49 -08:00
|
|
|
cat << ___EOF___ > $T/script
|
2014-02-27 20:26:57 -08:00
|
|
|
CONFIGFRAG="$CONFIGFRAG"; export CONFIGFRAG
|
2022-01-25 21:08:55 -08:00
|
|
|
RCUTORTURE="$RCUTORTURE"; export RCUTORTURE
|
2014-02-27 20:26:57 -08:00
|
|
|
PATH="$PATH"; export PATH
|
2019-05-11 17:59:52 -07:00
|
|
|
TORTURE_ALLOTED_CPUS="$TORTURE_ALLOTED_CPUS"; export TORTURE_ALLOTED_CPUS
|
2014-03-06 14:44:46 -08:00
|
|
|
TORTURE_BOOT_IMAGE="$TORTURE_BOOT_IMAGE"; export TORTURE_BOOT_IMAGE
|
2014-02-27 20:26:57 -08:00
|
|
|
TORTURE_BUILDONLY="$TORTURE_BUILDONLY"; export TORTURE_BUILDONLY
|
2014-02-26 14:28:43 -08:00
|
|
|
TORTURE_DEFCONFIG="$TORTURE_DEFCONFIG"; export TORTURE_DEFCONFIG
|
2014-02-27 20:26:57 -08:00
|
|
|
TORTURE_INITRD="$TORTURE_INITRD"; export TORTURE_INITRD
|
2017-05-01 17:49:29 -07:00
|
|
|
TORTURE_KCONFIG_ARG="$TORTURE_KCONFIG_ARG"; export TORTURE_KCONFIG_ARG
|
torture: Add gdb support
This commit adds a "--gdb" parameter to kvm.sh, which causes
"CONFIG_DEBUG_INFO=y" to be added to the Kconfig options, "nokaslr"
to be added to the boot parameters, and "-s -S" to be added to the qemu
arguments. Furthermore, the scripting prints messages telling the user
how to start up gdb for the run in question.
Because of the interactive nature of gdb sessions, only one "--configs"
scenario is permitted when "--gdb" is specified. For most torture types,
this means that a "--configs" argument is required, and that argument
must specify the single scenario of interest.
The usual cautions about breakpoints and timing apply, for example,
staring at your gdb prompt for too long will likely get you many
complaints, including RCU CPU stall warnings. Omar Sandoval further
suggests using gdb's "hbreak" command instead of the "break" command on
systems supporting hardware breakpoints, and further using the "commands"
option because the resulting non-interactive breakpoints are less likely
to get you RCU CPU stall warnings.
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2020-08-17 16:44:48 -07:00
|
|
|
TORTURE_KCONFIG_GDB_ARG="$TORTURE_KCONFIG_GDB_ARG"; export TORTURE_KCONFIG_GDB_ARG
|
|
|
|
|
TORTURE_BOOT_GDB_ARG="$TORTURE_BOOT_GDB_ARG"; export TORTURE_BOOT_GDB_ARG
|
|
|
|
|
TORTURE_QEMU_GDB_ARG="$TORTURE_QEMU_GDB_ARG"; export TORTURE_QEMU_GDB_ARG
|
2020-04-09 17:14:18 -07:00
|
|
|
TORTURE_KCONFIG_KASAN_ARG="$TORTURE_KCONFIG_KASAN_ARG"; export TORTURE_KCONFIG_KASAN_ARG
|
2020-04-07 17:31:35 -07:00
|
|
|
TORTURE_KCONFIG_KCSAN_ARG="$TORTURE_KCONFIG_KCSAN_ARG"; export TORTURE_KCONFIG_KCSAN_ARG
|
2014-02-27 20:26:57 -08:00
|
|
|
TORTURE_KMAKE_ARG="$TORTURE_KMAKE_ARG"; export TORTURE_KMAKE_ARG
|
torture: Provide bare-metal modprobe-based advice
In some environments, the torture-testing use of virtualization is
inconvenient. In such cases, the modprobe and rmmod commands may be used
to do torture testing, but significant setup is required to build, boot,
and modprobe a kernel so as to match a given torture-test scenario.
This commit therefore creates a "bare-metal" file in each results
directory containing steps to run the corresponding scenario using the
modprobe command on bare metal. For example, the contents of this file
after using kvm.sh to build an rcutorture TREE01 kernel, perhaps with
the --buildonly argument, is as follows:
To run this scenario on bare metal:
1. Set your bare-metal build tree to the state shown in this file:
/home/git/linux-rcu/tools/testing/selftests/rcutorture/res/2021.02.04-17.10.19/testid.txt
2. Update your bare-metal build tree's .config based on this file:
/home/git/linux-rcu/tools/testing/selftests/rcutorture/res/2021.02.04-17.10.19/TREE01/ConfigFragment
3. Make the bare-metal kernel's build system aware of your .config updates:
$ yes "" | make oldconfig
4. Build your bare-metal kernel.
5. Boot your bare-metal kernel with the following parameters:
maxcpus=8 nr_cpus=43 rcutree.gp_preinit_delay=3 rcutree.gp_init_delay=3 rcutree.gp_cleanup_delay=3 rcu_nocbs=0-1,3-7
6. Start the test with the following command:
$ modprobe rcutorture nocbs_nthreads=8 nocbs_toggle=1000 fwd_progress=0 onoff_interval=1000 onoff_holdoff=30 n_barrier_cbs=4 stat_interval=15 shutdown_secs=120 test_no_idle_hz=1 verbose=1
7. After some time, end the test with the following command:
$ rmmod rcutorture
8. Copy your bare-metal kernel's .config file, overwriting this file:
/home/git/linux-rcu/tools/testing/selftests/rcutorture/res/2021.02.04-17.10.19/TREE01/.config
9. Copy the console output from just before the modprobe to just after
the rmmod into this file:
/home/git/linux-rcu/tools/testing/selftests/rcutorture/res/2021.02.04-17.10.19/TREE01/console.log
10. Check for runtime errors using the following command:
$ tools/testing/selftests/rcutorture/bin/kvm-recheck.sh /home/git/linux-rcu/tools/testing/selftests/rcutorture/res/2021.02.04-17.10.19
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2021-02-03 15:44:29 -08:00
|
|
|
TORTURE_MOD="$TORTURE_MOD"; export TORTURE_MOD
|
2014-02-27 20:26:57 -08:00
|
|
|
TORTURE_QEMU_CMD="$TORTURE_QEMU_CMD"; export TORTURE_QEMU_CMD
|
|
|
|
|
TORTURE_QEMU_INTERACTIVE="$TORTURE_QEMU_INTERACTIVE"; export TORTURE_QEMU_INTERACTIVE
|
|
|
|
|
TORTURE_QEMU_MAC="$TORTURE_QEMU_MAC"; export TORTURE_QEMU_MAC
|
2018-01-12 14:19:05 -08:00
|
|
|
TORTURE_QEMU_MEM="$TORTURE_QEMU_MEM"; export TORTURE_QEMU_MEM
|
2015-10-01 11:41:06 -07:00
|
|
|
TORTURE_SHUTDOWN_GRACE="$TORTURE_SHUTDOWN_GRACE"; export TORTURE_SHUTDOWN_GRACE
|
2014-02-27 20:26:57 -08:00
|
|
|
TORTURE_SUITE="$TORTURE_SUITE"; export TORTURE_SUITE
|
2019-05-11 20:18:00 -07:00
|
|
|
TORTURE_TRUST_MAKE="$TORTURE_TRUST_MAKE"; export TORTURE_TRUST_MAKE
|
2014-02-27 17:11:11 -08:00
|
|
|
if ! test -e $resdir
|
|
|
|
|
then
|
|
|
|
|
mkdir -p "$resdir" || :
|
|
|
|
|
fi
|
2020-11-11 11:09:17 -08:00
|
|
|
mkdir -p $resdir/$ds
|
2020-06-09 17:58:30 -07:00
|
|
|
TORTURE_RESDIR="$resdir/$ds"; export TORTURE_RESDIR
|
2020-12-11 16:59:40 -08:00
|
|
|
TORTURE_STOPFILE="$resdir/$ds/STOP.1"; export TORTURE_STOPFILE
|
2014-02-27 17:11:11 -08:00
|
|
|
echo Results directory: $resdir/$ds
|
|
|
|
|
echo $scriptname $args
|
|
|
|
|
touch $resdir/$ds/log
|
|
|
|
|
echo $scriptname $args >> $resdir/$ds/log
|
2021-02-17 14:04:01 -08:00
|
|
|
echo ${TORTURE_SUITE} > $resdir/$ds/torture_suite
|
2021-02-04 17:20:45 -08:00
|
|
|
echo Build directory: `pwd` > $resdir/$ds/testid.txt
|
2014-02-27 17:11:11 -08:00
|
|
|
if test -d .git
|
|
|
|
|
then
|
2021-02-04 17:20:45 -08:00
|
|
|
echo Current commit: `git rev-parse HEAD` >> $resdir/$ds/testid.txt
|
|
|
|
|
echo >> $resdir/$ds/testid.txt
|
|
|
|
|
echo ' ---' Output of "'"git status"'": >> $resdir/$ds/testid.txt
|
2014-02-27 17:11:11 -08:00
|
|
|
git status >> $resdir/$ds/testid.txt
|
2021-02-04 17:20:45 -08:00
|
|
|
echo >> $resdir/$ds/testid.txt
|
|
|
|
|
echo >> $resdir/$ds/testid.txt
|
|
|
|
|
echo ' ---' Output of "'"git diff HEAD"'": >> $resdir/$ds/testid.txt
|
2017-04-27 10:24:08 -07:00
|
|
|
git diff HEAD >> $resdir/$ds/testid.txt
|
2014-02-27 17:11:11 -08:00
|
|
|
fi
|
2014-02-07 10:29:49 -08:00
|
|
|
___EOF___
|
2021-07-07 15:49:40 -07:00
|
|
|
kvm-assign-cpus.sh /sys/devices/system/node > $T/cpuarray.awk
|
|
|
|
|
kvm-get-cpus-script.sh $T/cpuarray.awk $T/dumpbatches.awk
|
|
|
|
|
cat << '___EOF___' >> $T/dumpbatches.awk
|
2021-07-07 13:42:27 -07:00
|
|
|
BEGIN {
|
2014-01-15 15:48:41 -08:00
|
|
|
i = 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
{
|
|
|
|
|
cf[i] = $1;
|
|
|
|
|
cpus[i] = $2;
|
|
|
|
|
i++;
|
|
|
|
|
}
|
|
|
|
|
|
2014-01-17 21:56:57 -08:00
|
|
|
# Dump out the scripting required to run one test batch.
|
2021-07-07 15:49:40 -07:00
|
|
|
function dump(first, pastlast, batchnum, affinitylist)
|
2014-01-15 15:48:41 -08:00
|
|
|
{
|
2017-11-03 19:17:27 +09:00
|
|
|
print "echo ----Start batch " batchnum ": `date` | tee -a " rd "log";
|
rcutorture: Don't wait for kernel when all builds fail
Currently, rcutorture groups runs in batches, building each scenario in
a given batch, then invoking qemu to run all the kernels in the batch.
Of course, if a given scenario's kernel fails to build, there is no qemu
run for that scenario. And if all of the kernels in a given batch fail
to build, there are no runs, and rcutorture immediately starts on the
next batch.
But not if --jitter has been specified, which it is by default. In this
case, the jitter scripts are started unconditionally, and rcutorture
waits for them to complete, even though there are no kernels to run.
This commit therefore checks for this situation, and refuses to start
jitter unless at least one of the kernels in the batch built successfully.
This saves substantial time when all scenarios' kernels fail to build,
particularly if a long --duration was specified.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
2017-05-02 15:22:26 -07:00
|
|
|
print "needqemurun="
|
2014-01-15 15:48:41 -08:00
|
|
|
jn=1
|
2021-02-16 15:32:23 -08:00
|
|
|
njitter = 0;
|
|
|
|
|
split(jitter, ja);
|
|
|
|
|
if (ja[1] == -1 && ncpus == 0)
|
|
|
|
|
njitter = 1;
|
|
|
|
|
else if (ja[1] == -1)
|
|
|
|
|
njitter = ncpus;
|
|
|
|
|
else
|
|
|
|
|
njitter = ja[1];
|
|
|
|
|
print "TORTURE_JITTER_START=\". jitterstart.sh " njitter " " rd " " dur " " ja[2] " " ja[3] "\"; export TORTURE_JITTER_START";
|
|
|
|
|
print "TORTURE_JITTER_STOP=\". jitterstop.sh " rd " \"; export TORTURE_JITTER_STOP"
|
2014-01-15 15:48:41 -08:00
|
|
|
for (j = first; j < pastlast; j++) {
|
2014-01-17 03:29:12 -08:00
|
|
|
cpusr[jn] = cpus[j];
|
2014-01-15 15:48:41 -08:00
|
|
|
if (cfrep[cf[j]] == "") {
|
2014-01-17 03:29:12 -08:00
|
|
|
cfr[jn] = cf[j];
|
2014-01-15 15:48:41 -08:00
|
|
|
cfrep[cf[j]] = 1;
|
|
|
|
|
} else {
|
|
|
|
|
cfrep[cf[j]]++;
|
2014-01-17 03:29:12 -08:00
|
|
|
cfr[jn] = cf[j] "." cfrep[cf[j]];
|
2014-01-15 15:48:41 -08:00
|
|
|
}
|
2021-02-10 15:15:13 -08:00
|
|
|
builddir=rd cfr[jn] "/build";
|
2014-01-17 22:08:09 -08:00
|
|
|
if (cpusr[jn] > ncpus && ncpus != 0)
|
2015-02-07 20:08:51 -08:00
|
|
|
ovf = "-ovf";
|
2014-01-17 22:08:09 -08:00
|
|
|
else
|
|
|
|
|
ovf = "";
|
2017-11-03 19:17:27 +09:00
|
|
|
print "echo ", cfr[jn], cpusr[jn] ovf ": Starting build. `date` | tee -a " rd "log";
|
2014-01-17 03:29:12 -08:00
|
|
|
print "mkdir " rd cfr[jn] " || :";
|
2021-02-10 15:15:13 -08:00
|
|
|
print "touch " builddir ".wait";
|
2021-07-07 15:49:40 -07:00
|
|
|
affinitylist = "";
|
|
|
|
|
if (gotcpus()) {
|
|
|
|
|
affinitylist = nextcpus(cpusr[jn]);
|
|
|
|
|
}
|
|
|
|
|
if (affinitylist ~ /^[0-9,-][0-9,-]*$/)
|
|
|
|
|
print "export TORTURE_AFFINITY=" affinitylist;
|
|
|
|
|
else
|
|
|
|
|
print "export TORTURE_AFFINITY=";
|
2021-02-10 15:15:13 -08:00
|
|
|
print "kvm-test-1-run.sh " CONFIGDIR cf[j], rd cfr[jn], dur " \"" TORTURE_QEMU_ARG "\" \"" TORTURE_BOOTARGS "\" > " rd cfr[jn] "/kvm-test-1-run.sh.out 2>&1 &"
|
2017-11-03 19:17:27 +09:00
|
|
|
print "echo ", cfr[jn], cpusr[jn] ovf ": Waiting for build to complete. `date` | tee -a " rd "log";
|
2014-01-15 15:48:41 -08:00
|
|
|
print "while test -f " builddir ".wait"
|
|
|
|
|
print "do"
|
|
|
|
|
print "\tsleep 1"
|
|
|
|
|
print "done"
|
2017-11-03 19:17:27 +09:00
|
|
|
print "echo ", cfr[jn], cpusr[jn] ovf ": Build complete. `date` | tee -a " rd "log";
|
2014-01-15 15:48:41 -08:00
|
|
|
jn++;
|
|
|
|
|
}
|
2021-02-10 16:28:44 -08:00
|
|
|
print "runfiles="
|
2014-01-15 15:48:41 -08:00
|
|
|
for (j = 1; j < jn; j++) {
|
2021-02-10 15:15:13 -08:00
|
|
|
builddir=rd cfr[j] "/build";
|
2021-02-10 16:28:44 -08:00
|
|
|
if (TORTURE_BUILDONLY)
|
|
|
|
|
print "rm -f " builddir ".ready"
|
|
|
|
|
else
|
|
|
|
|
print "mv " builddir ".ready " builddir ".run"
|
|
|
|
|
print "runfiles=\"$runfiles " builddir ".run\""
|
|
|
|
|
fi
|
rcutorture: Don't wait for kernel when all builds fail
Currently, rcutorture groups runs in batches, building each scenario in
a given batch, then invoking qemu to run all the kernels in the batch.
Of course, if a given scenario's kernel fails to build, there is no qemu
run for that scenario. And if all of the kernels in a given batch fail
to build, there are no runs, and rcutorture immediately starts on the
next batch.
But not if --jitter has been specified, which it is by default. In this
case, the jitter scripts are started unconditionally, and rcutorture
waits for them to complete, even though there are no kernels to run.
This commit therefore checks for this situation, and refuses to start
jitter unless at least one of the kernels in the batch built successfully.
This saves substantial time when all scenarios' kernels fail to build,
particularly if a long --duration was specified.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
2017-05-02 15:22:26 -07:00
|
|
|
print "if test -f \"" rd cfr[j] "/builtkernel\""
|
2014-04-29 09:53:34 -07:00
|
|
|
print "then"
|
2017-11-03 19:17:27 +09:00
|
|
|
print "\techo ----", cfr[j], cpusr[j] ovf ": Kernel present. `date` | tee -a " rd "log";
|
rcutorture: Don't wait for kernel when all builds fail
Currently, rcutorture groups runs in batches, building each scenario in
a given batch, then invoking qemu to run all the kernels in the batch.
Of course, if a given scenario's kernel fails to build, there is no qemu
run for that scenario. And if all of the kernels in a given batch fail
to build, there are no runs, and rcutorture immediately starts on the
next batch.
But not if --jitter has been specified, which it is by default. In this
case, the jitter scripts are started unconditionally, and rcutorture
waits for them to complete, even though there are no kernels to run.
This commit therefore checks for this situation, and refuses to start
jitter unless at least one of the kernels in the batch built successfully.
This saves substantial time when all scenarios' kernels fail to build,
particularly if a long --duration was specified.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
2017-05-02 15:22:26 -07:00
|
|
|
print "\tneedqemurun=1"
|
2014-04-29 09:53:34 -07:00
|
|
|
print "fi"
|
2014-01-15 15:48:41 -08:00
|
|
|
}
|
2016-09-27 11:56:12 -07:00
|
|
|
if (TORTURE_BUILDONLY && njitter != 0) {
|
|
|
|
|
njitter = 0;
|
2017-11-03 19:17:27 +09:00
|
|
|
print "echo Build-only run, so suppressing jitter | tee -a " rd "log"
|
2016-09-27 11:56:12 -07:00
|
|
|
}
|
rcutorture: Don't wait for kernel when all builds fail
Currently, rcutorture groups runs in batches, building each scenario in
a given batch, then invoking qemu to run all the kernels in the batch.
Of course, if a given scenario's kernel fails to build, there is no qemu
run for that scenario. And if all of the kernels in a given batch fail
to build, there are no runs, and rcutorture immediately starts on the
next batch.
But not if --jitter has been specified, which it is by default. In this
case, the jitter scripts are started unconditionally, and rcutorture
waits for them to complete, even though there are no kernels to run.
This commit therefore checks for this situation, and refuses to start
jitter unless at least one of the kernels in the batch built successfully.
This saves substantial time when all scenarios' kernels fail to build,
particularly if a long --duration was specified.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
2017-05-02 15:22:26 -07:00
|
|
|
if (TORTURE_BUILDONLY) {
|
|
|
|
|
print "needqemurun="
|
|
|
|
|
}
|
|
|
|
|
print "if test -n \"$needqemurun\""
|
2014-04-29 09:53:34 -07:00
|
|
|
print "then"
|
2017-11-03 19:17:27 +09:00
|
|
|
print "\techo ---- Starting kernels. `date` | tee -a " rd "log";
|
2021-02-16 15:32:23 -08:00
|
|
|
print "\t$TORTURE_JITTER_START";
|
2021-02-10 16:28:44 -08:00
|
|
|
print "\twhile ls $runfiles > /dev/null 2>&1"
|
|
|
|
|
print "\tdo"
|
|
|
|
|
print "\t\t:"
|
|
|
|
|
print "\tdone"
|
2021-02-16 15:32:23 -08:00
|
|
|
print "\t$TORTURE_JITTER_STOP";
|
2017-11-03 19:17:27 +09:00
|
|
|
print "\techo ---- All kernel runs complete. `date` | tee -a " rd "log";
|
rcutorture: Don't wait for kernel when all builds fail
Currently, rcutorture groups runs in batches, building each scenario in
a given batch, then invoking qemu to run all the kernels in the batch.
Of course, if a given scenario's kernel fails to build, there is no qemu
run for that scenario. And if all of the kernels in a given batch fail
to build, there are no runs, and rcutorture immediately starts on the
next batch.
But not if --jitter has been specified, which it is by default. In this
case, the jitter scripts are started unconditionally, and rcutorture
waits for them to complete, even though there are no kernels to run.
This commit therefore checks for this situation, and refuses to start
jitter unless at least one of the kernels in the batch built successfully.
This saves substantial time when all scenarios' kernels fail to build,
particularly if a long --duration was specified.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
2017-05-02 15:22:26 -07:00
|
|
|
print "else"
|
|
|
|
|
print "\twait"
|
2017-11-03 19:17:27 +09:00
|
|
|
print "\techo ---- No kernel runs. `date` | tee -a " rd "log";
|
2014-04-29 09:53:34 -07:00
|
|
|
print "fi"
|
2014-01-15 15:48:41 -08:00
|
|
|
for (j = 1; j < jn; j++) {
|
2017-11-03 19:17:27 +09:00
|
|
|
print "echo ----", cfr[j], cpusr[j] ovf ": Build/run results: | tee -a " rd "log";
|
|
|
|
|
print "cat " rd cfr[j] "/kvm-test-1-run.sh.out | tee -a " rd "log";
|
2014-01-15 15:48:41 -08:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
END {
|
|
|
|
|
njobs = i;
|
|
|
|
|
nc = ncpus;
|
|
|
|
|
first = 0;
|
2015-09-30 22:11:48 -07:00
|
|
|
batchnum = 1;
|
2014-01-17 21:56:57 -08:00
|
|
|
|
|
|
|
|
# Each pass through the following loop considers one test.
|
2014-01-15 15:48:41 -08:00
|
|
|
for (i = 0; i < njobs; i++) {
|
|
|
|
|
if (ncpus == 0) {
|
2014-01-17 21:56:57 -08:00
|
|
|
# Sequential test specified, each test its own batch.
|
2015-09-30 22:11:48 -07:00
|
|
|
dump(i, i + 1, batchnum);
|
2014-01-15 15:48:41 -08:00
|
|
|
first = i;
|
2015-09-30 22:11:48 -07:00
|
|
|
batchnum++;
|
2014-01-15 15:48:41 -08:00
|
|
|
} else if (nc < cpus[i] && i != 0) {
|
2014-01-17 21:56:57 -08:00
|
|
|
# Out of CPUs, dump out a batch.
|
2015-09-30 22:11:48 -07:00
|
|
|
dump(first, i, batchnum);
|
2014-01-15 15:48:41 -08:00
|
|
|
first = i;
|
|
|
|
|
nc = ncpus;
|
2015-09-30 22:11:48 -07:00
|
|
|
batchnum++;
|
2014-01-15 15:48:41 -08:00
|
|
|
}
|
2014-01-17 21:56:57 -08:00
|
|
|
# Account for the CPUs needed by the current test.
|
2014-01-15 15:48:41 -08:00
|
|
|
nc -= cpus[i];
|
|
|
|
|
}
|
2014-01-17 21:56:57 -08:00
|
|
|
# Dump the last batch.
|
2014-01-15 15:48:41 -08:00
|
|
|
if (ncpus != 0)
|
2015-09-30 22:11:48 -07:00
|
|
|
dump(first, i, batchnum);
|
2021-07-07 13:42:27 -07:00
|
|
|
}
|
|
|
|
|
___EOF___
|
|
|
|
|
awk < $T/cfgcpu.pack \
|
|
|
|
|
-v TORTURE_BUILDONLY="$TORTURE_BUILDONLY" \
|
|
|
|
|
-v CONFIGDIR="$CONFIGFRAG/" \
|
2022-01-25 21:08:55 -08:00
|
|
|
-v RCUTORTURE="$RCUTORTURE" \
|
2021-07-07 13:42:27 -07:00
|
|
|
-v ncpus=$cpus \
|
|
|
|
|
-v jitter="$jitter" \
|
|
|
|
|
-v rd=$resdir/$ds/ \
|
|
|
|
|
-v dur=$dur \
|
|
|
|
|
-v TORTURE_QEMU_ARG="$TORTURE_QEMU_ARG" \
|
|
|
|
|
-v TORTURE_BOOTARGS="$TORTURE_BOOTARGS" \
|
|
|
|
|
-f $T/dumpbatches.awk >> $T/script
|
2021-03-17 13:21:41 -07:00
|
|
|
echo kvm-end-run-stats.sh "$resdir/$ds" "$starttime" >> $T/script
|
2014-02-27 17:11:11 -08:00
|
|
|
|
2021-02-17 14:40:03 -08:00
|
|
|
# Extract the tests and their batches from the script.
|
|
|
|
|
egrep 'Start batch|Starting build\.' $T/script | grep -v ">>" |
|
|
|
|
|
sed -e 's/:.*$//' -e 's/^echo //' -e 's/-ovf//' |
|
|
|
|
|
awk '
|
|
|
|
|
/^----Start/ {
|
|
|
|
|
batchno = $3;
|
|
|
|
|
next;
|
|
|
|
|
}
|
|
|
|
|
{
|
|
|
|
|
print batchno, $1, $2
|
|
|
|
|
}' > $T/batches
|
|
|
|
|
|
2021-03-04 17:21:17 -08:00
|
|
|
# As above, but one line per batch.
|
|
|
|
|
grep -v '^#' $T/batches | awk '
|
|
|
|
|
BEGIN {
|
|
|
|
|
oldbatch = 1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
{
|
|
|
|
|
if (oldbatch != $1) {
|
|
|
|
|
print ++n ". " curbatch;
|
|
|
|
|
curbatch = "";
|
|
|
|
|
oldbatch = $1;
|
|
|
|
|
}
|
|
|
|
|
curbatch = curbatch " " $2;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
END {
|
|
|
|
|
print ++n ". " curbatch;
|
|
|
|
|
}' > $T/scenarios
|
|
|
|
|
|
2014-01-17 03:10:16 -08:00
|
|
|
if test "$dryrun" = script
|
|
|
|
|
then
|
|
|
|
|
cat $T/script
|
|
|
|
|
exit 0
|
|
|
|
|
elif test "$dryrun" = sched
|
|
|
|
|
then
|
2014-01-17 21:56:57 -08:00
|
|
|
# Extract the test run schedule from the script.
|
2020-12-11 16:26:50 -08:00
|
|
|
egrep 'Start batch|Starting build\.' $T/script | grep -v ">>" |
|
2014-01-17 03:10:16 -08:00
|
|
|
sed -e 's/:.*$//' -e 's/^echo //'
|
2020-11-08 15:52:30 -08:00
|
|
|
nbuilds="`grep 'Starting build\.' $T/script |
|
|
|
|
|
grep -v ">>" | sed -e 's/:.*$//' -e 's/^echo //' |
|
|
|
|
|
awk '{ print $1 }' | grep -v '\.' | wc -l`"
|
|
|
|
|
echo Total number of builds: $nbuilds
|
2020-11-08 15:38:26 -08:00
|
|
|
nbatches="`grep 'Start batch' $T/script | grep -v ">>" | wc -l`"
|
|
|
|
|
echo Total number of batches: $nbatches
|
2014-01-17 03:10:16 -08:00
|
|
|
exit 0
|
2020-12-11 16:26:50 -08:00
|
|
|
elif test "$dryrun" = batches
|
|
|
|
|
then
|
2021-02-17 14:40:03 -08:00
|
|
|
cat $T/batches
|
|
|
|
|
exit 0
|
2021-03-04 17:21:17 -08:00
|
|
|
elif test "$dryrun" = scenarios
|
|
|
|
|
then
|
|
|
|
|
cat $T/scenarios
|
|
|
|
|
exit 0
|
2014-01-17 03:10:16 -08:00
|
|
|
else
|
2021-02-17 14:40:03 -08:00
|
|
|
# Not a dryrun. Record the batches and the number of CPUs, then run the script.
|
2020-11-26 15:27:57 -08:00
|
|
|
bash $T/script
|
2020-11-22 09:55:34 -08:00
|
|
|
ret=$?
|
2021-02-17 14:40:03 -08:00
|
|
|
cp $T/batches $resdir/$ds/batches
|
2021-03-04 17:21:17 -08:00
|
|
|
cp $T/scenarios $resdir/$ds/scenarios
|
2021-02-17 14:40:03 -08:00
|
|
|
echo '#' cpus=$cpus >> $resdir/$ds/batches
|
2020-11-22 09:55:34 -08:00
|
|
|
exit $ret
|
2014-01-17 03:10:16 -08:00
|
|
|
fi
|
2014-01-15 15:48:41 -08:00
|
|
|
|
2013-10-15 12:11:24 -07:00
|
|
|
# Tracing: trace_event=rcu:rcu_grace_period,rcu:rcu_future_grace_period,rcu:rcu_grace_period_init,rcu:rcu_nocb_wake,rcu:rcu_preempt_task,rcu:rcu_unlock_preempted_task,rcu:rcu_quiescent_state_report,rcu:rcu_fqs,rcu:rcu_callback,rcu:rcu_kfree_callback,rcu:rcu_batch_start,rcu:rcu_invoke_callback,rcu:rcu_invoke_kfree_callback,rcu:rcu_batch_end,rcu:rcu_torture_read,rcu:rcu_barrier
|
2019-05-01 13:26:11 -07:00
|
|
|
# Function-graph tracing: ftrace=function_graph ftrace_graph_filter=sched_setaffinity,migration_cpu_stop
|
|
|
|
|
# Also --kconfig "CONFIG_FUNCTION_TRACER=y CONFIG_FUNCTION_GRAPH_TRACER=y"
|
2020-06-16 11:16:18 -07:00
|
|
|
# Control buffer size: --bootargs trace_buf_size=3k
|
|
|
|
|
# Get trace-buffer dumps on all oopses: --bootargs ftrace_dump_on_oops
|
|
|
|
|
# Ditto, but dump only the oopsing CPU: --bootargs ftrace_dump_on_oops=orig_cpu
|
|
|
|
|
# Heavy-handed way to also dump on warnings: --bootargs panic_on_warn
|