test the schedulers in the github workflow using virtme-ng #51
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
arighi
force-pushed
the
virtme-ng-github-workflow
branch
2 times, most recently
from
a7320e7
to
8950aed
Compare
Periodically flush stdout to help following the scheduler progress during testing. Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Periodically flush stdout to help following the scheduler progress during testing. Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
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: - sched-ext#49 - sched-ext/sched_ext#101 Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
arighi
force-pushed
the
virtme-ng-github-workflow
branch
from
8950aed
to
05f5c69
Compare
|
Wow, awesome, thanks Andrea! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Use virtme-ng to test the schedulers in the github workflow.
Keep in mind that I've only tested this locally (using
gh act), so in the actual github workflow it may behave differently and it probably requires more testing / planning.I've opened the PR to start some discussions / suggestions / ideas for now.
Overall, I think it can be really useful, I've already triggered a few bugs with this (see #49, sched-ext/sched_ext#101 and sched-ext/sched_ext#74 (comment)).