scx-upstream/meson-scripts/test_sched

61 lines
1.7 KiB
Plaintext
Raw Normal View History

ci: use virtme-ng to test the schedulers Use virtme-ng to run the schedulers after they're built; virtme-ng allows to pick an arbitrary sched-ext enabled kernel and run it virtualizing the entire user-space root filesystem, so we can basically exceute the recompiled schedulers inside such kernel. This should allow to catch potential run-time issue in advance (both in the kernel and the schedulers). The sched-ext kernel is taken from the Ubuntu ppa (ppa:arighi/sched-ext) at the moment, since it is the easiest / fastest way to get a precompiled sched-ext kernel to run inside the Ubuntu 22.04 testing environment. The schedulers are tested using the new meson target "test_sched", the specific actions are defined in meson-scripts/test_sched. By default each test has a timeout of 30 sec, after the virtme-ng completes the boot (that should be enough to initialize the scheduler and run the scheduler for some seconds), while the total lifetime of the virtme-ng guest is set to 60 sec, after this time the guest will be killed (this allows to catch potential kernel crashes / hangs). If a single scheduler fails the test, the entire "test_sched" action will be interrupted and the overall test result will be considered a failure. At the moment scx_layered is excluded from the tests, because it requires a special configuration (we should probably pre-generate a default config in the workflow actions and change the scheduler to use the default config if it's executed without any argument). Moreover, scx_flatcg is also temporarily excluded from the tests, because of these known issues: - https://github.com/sched-ext/scx/issues/49 - https://github.com/sched-ext/sched_ext/pull/101 Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
2023-12-24 08:09:25 +00:00
#!/bin/bash
#
# Run a scheduler for TIMEOUT seconds inside virtme-ng and catch potential
# errors, then unload the scheduler and return the exit status.
# Maximum time for each scheduler run.
TEST_TIMEOUT=30
# Maximum timeout for the guest used for each scheduler run (this is used to
# hard-shutdown the guest in case of system hangs).
GUEST_TIMEOUT=60
# List of schedulers to test
#
# TODO:
# - scx_layered: temporarily excluded because it
# cannot run with a default configuration
# - scx_flatcg, scx_pair: excluded until cgroup support lands upstream
# - scx_mitosis: not ready yet
ci: use virtme-ng to test the schedulers Use virtme-ng to run the schedulers after they're built; virtme-ng allows to pick an arbitrary sched-ext enabled kernel and run it virtualizing the entire user-space root filesystem, so we can basically exceute the recompiled schedulers inside such kernel. This should allow to catch potential run-time issue in advance (both in the kernel and the schedulers). The sched-ext kernel is taken from the Ubuntu ppa (ppa:arighi/sched-ext) at the moment, since it is the easiest / fastest way to get a precompiled sched-ext kernel to run inside the Ubuntu 22.04 testing environment. The schedulers are tested using the new meson target "test_sched", the specific actions are defined in meson-scripts/test_sched. By default each test has a timeout of 30 sec, after the virtme-ng completes the boot (that should be enough to initialize the scheduler and run the scheduler for some seconds), while the total lifetime of the virtme-ng guest is set to 60 sec, after this time the guest will be killed (this allows to catch potential kernel crashes / hangs). If a single scheduler fails the test, the entire "test_sched" action will be interrupted and the overall test result will be considered a failure. At the moment scx_layered is excluded from the tests, because it requires a special configuration (we should probably pre-generate a default config in the workflow actions and change the scheduler to use the default config if it's executed without any argument). Moreover, scx_flatcg is also temporarily excluded from the tests, because of these known issues: - https://github.com/sched-ext/scx/issues/49 - https://github.com/sched-ext/sched_ext/pull/101 Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
2023-12-24 08:09:25 +00:00
#
SCHEDULERS="scx_simple scx_central scx_nest scx_rusty scx_rustland scx_bpfland"
ci: use virtme-ng to test the schedulers Use virtme-ng to run the schedulers after they're built; virtme-ng allows to pick an arbitrary sched-ext enabled kernel and run it virtualizing the entire user-space root filesystem, so we can basically exceute the recompiled schedulers inside such kernel. This should allow to catch potential run-time issue in advance (both in the kernel and the schedulers). The sched-ext kernel is taken from the Ubuntu ppa (ppa:arighi/sched-ext) at the moment, since it is the easiest / fastest way to get a precompiled sched-ext kernel to run inside the Ubuntu 22.04 testing environment. The schedulers are tested using the new meson target "test_sched", the specific actions are defined in meson-scripts/test_sched. By default each test has a timeout of 30 sec, after the virtme-ng completes the boot (that should be enough to initialize the scheduler and run the scheduler for some seconds), while the total lifetime of the virtme-ng guest is set to 60 sec, after this time the guest will be killed (this allows to catch potential kernel crashes / hangs). If a single scheduler fails the test, the entire "test_sched" action will be interrupted and the overall test result will be considered a failure. At the moment scx_layered is excluded from the tests, because it requires a special configuration (we should probably pre-generate a default config in the workflow actions and change the scheduler to use the default config if it's executed without any argument). Moreover, scx_flatcg is also temporarily excluded from the tests, because of these known issues: - https://github.com/sched-ext/scx/issues/49 - https://github.com/sched-ext/sched_ext/pull/101 Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
2023-12-24 08:09:25 +00:00
if [ ! -x `which vng` ]; then
echo "vng not found, please install virtme-ng to enable testing"
exit 1
fi
if [ $# -lt 1 ]; then
echo "Usage: $0 VMLINUZ"
exit 1
fi
kernel=$1
for sched in ${SCHEDULERS}; do
sched_path=$(find -type f -executable -name ${sched})
if [ ! -n "${sched_path}" ]; then
echo "${sched}: binary not found"
echo "FAIL: ${sched}"
exit 1
fi
echo "testing ${sched_path}"
rm -f /tmp/output
timeout --preserve-status ${GUEST_TIMEOUT} \
vng --force-9p -v -r ${kernel} -- \
ci: use virtme-ng to test the schedulers Use virtme-ng to run the schedulers after they're built; virtme-ng allows to pick an arbitrary sched-ext enabled kernel and run it virtualizing the entire user-space root filesystem, so we can basically exceute the recompiled schedulers inside such kernel. This should allow to catch potential run-time issue in advance (both in the kernel and the schedulers). The sched-ext kernel is taken from the Ubuntu ppa (ppa:arighi/sched-ext) at the moment, since it is the easiest / fastest way to get a precompiled sched-ext kernel to run inside the Ubuntu 22.04 testing environment. The schedulers are tested using the new meson target "test_sched", the specific actions are defined in meson-scripts/test_sched. By default each test has a timeout of 30 sec, after the virtme-ng completes the boot (that should be enough to initialize the scheduler and run the scheduler for some seconds), while the total lifetime of the virtme-ng guest is set to 60 sec, after this time the guest will be killed (this allows to catch potential kernel crashes / hangs). If a single scheduler fails the test, the entire "test_sched" action will be interrupted and the overall test result will be considered a failure. At the moment scx_layered is excluded from the tests, because it requires a special configuration (we should probably pre-generate a default config in the workflow actions and change the scheduler to use the default config if it's executed without any argument). Moreover, scx_flatcg is also temporarily excluded from the tests, because of these known issues: - https://github.com/sched-ext/scx/issues/49 - https://github.com/sched-ext/sched_ext/pull/101 Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
2023-12-24 08:09:25 +00:00
"timeout --foreground --preserve-status ${TEST_TIMEOUT} ${sched_path}" \
2> >(tee /tmp/output) </dev/null
grep -v " Speculative Return Stack Overflow" /tmp/output | \
sed -n -e '/\bBUG:/q1' \
-e '/\bWARNING:/q1' \
-e '/\berror\b/Iq1' \
-e '/\bstall/Iq1' \
-e '/\btimeout\b/Iq1'
ci: use virtme-ng to test the schedulers Use virtme-ng to run the schedulers after they're built; virtme-ng allows to pick an arbitrary sched-ext enabled kernel and run it virtualizing the entire user-space root filesystem, so we can basically exceute the recompiled schedulers inside such kernel. This should allow to catch potential run-time issue in advance (both in the kernel and the schedulers). The sched-ext kernel is taken from the Ubuntu ppa (ppa:arighi/sched-ext) at the moment, since it is the easiest / fastest way to get a precompiled sched-ext kernel to run inside the Ubuntu 22.04 testing environment. The schedulers are tested using the new meson target "test_sched", the specific actions are defined in meson-scripts/test_sched. By default each test has a timeout of 30 sec, after the virtme-ng completes the boot (that should be enough to initialize the scheduler and run the scheduler for some seconds), while the total lifetime of the virtme-ng guest is set to 60 sec, after this time the guest will be killed (this allows to catch potential kernel crashes / hangs). If a single scheduler fails the test, the entire "test_sched" action will be interrupted and the overall test result will be considered a failure. At the moment scx_layered is excluded from the tests, because it requires a special configuration (we should probably pre-generate a default config in the workflow actions and change the scheduler to use the default config if it's executed without any argument). Moreover, scx_flatcg is also temporarily excluded from the tests, because of these known issues: - https://github.com/sched-ext/scx/issues/49 - https://github.com/sched-ext/sched_ext/pull/101 Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
2023-12-24 08:09:25 +00:00
res=$?
if [ ${res} -ne 0 ]; then
echo "FAIL: ${sched}"
exit 1
else
echo "OK: ${sched}"
fi
done