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
|
|
|
|
#
|
2024-02-24 09:24:06 +00:00
|
|
|
SCHEDULERS="scx_simple scx_central scx_flatcg scx_nest scx_pair scx_rusty scx_rustland"
|
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 --disable-microvm -v -r ${kernel} -- \
|
|
|
|
"timeout --foreground --preserve-status ${TEST_TIMEOUT} ${sched_path}" \
|
2024-02-05 16:53:55 +00:00
|
|
|
2> >(tee /tmp/output) </dev/null
|
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
|
|
|
sed -n -e '/\bBUG:/q1' \
|
|
|
|
-e '/\bWARNING:/q1' \
|
|
|
|
-e '/\berror\b/Iq1' \
|
|
|
|
-e '/\bstall/Iq1' \
|
|
|
|
-e '/\btimeout\b/Iq1' /tmp/output
|
|
|
|
res=$?
|
|
|
|
if [ ${res} -ne 0 ]; then
|
|
|
|
echo "FAIL: ${sched}"
|
|
|
|
exit 1
|
|
|
|
else
|
|
|
|
echo "OK: ${sched}"
|
|
|
|
fi
|
|
|
|
done
|