JakeHillion/scx
1
0
Fork 0
mirror of https://github.com/JakeHillion/scx.git synced 2024-11-26 19:30:24 +00:00
Code Issues Packages Projects Releases Wiki Activity
815f1263b2
scx/.github/workflows/build-scheds.yml

79 lines
3.2 KiB
YAML
Raw Normal View History

scx: Add CI action that builds schedulers for PRs When Ubuntu ships with sched_ext, we can also maybe test loading the schedulers (not sure if the runners can run as root though). For now, we should at least have a CI job that lets us verify that the schedulers can _build_. To that end, this patch adds a basic CI action that builds the schedulers. As is, this is a bit brittle in that we're having to manually download and install a few dependencies. I don't see a better way for now without hosting our own runners with our own containers, but that's a bigger investment. For now, hopefully this will get us _some_ coverage. Signed-off-by: David Vernet <void@manifault.com>
2023-12-15 22:07:51 +00:00
name: build-scheds
run-name: ${{ github.actor }} PR run
ci: Only do CI runs for pull requests We're basically always runnin two CI jobs: one for a remote push, and another for when a PR is opened. These are essentially measuring the same thing, so let's save CI bandwidth and just do a PR run. This will hopefully make things a bit less noisy as well. Signed-off-by: David Vernet <void@manifault.com>
2024-02-04 22:12:46 +00:00
on: [pull_request]
scx: Add CI action that builds schedulers for PRs When Ubuntu ships with sched_ext, we can also maybe test loading the schedulers (not sure if the runners can run as root though). For now, we should at least have a CI job that lets us verify that the schedulers can _build_. To that end, this patch adds a basic CI action that builds the schedulers. As is, this is a bit brittle in that we're having to manually download and install a few dependencies. I don't see a better way for now without hosting our own runners with our own containers, but that's a bigger investment. For now, hopefully this will get us _some_ coverage. Signed-off-by: David Vernet <void@manifault.com>
2023-12-15 22:07:51 +00:00
jobs:
build-schedulers:
ci: Run CI job on Ubuntu 22.04 Andrea pointed out that we can and should be using Ubuntu 22.04. Unfortunately it still doesn't ship some of the deps we need like clang-17, but it does at least ship virtme-ng, so it's good for us to use this so that we can actually test running the schedulers in a virtme-ng VM when it supports being run in docker. Also, update the job to run on pushes, and not just when a PR is opened Suggested-by: Andrea Righi <andrea.righi@canonical.com> Signed-off-by: David Vernet <void@manifault.com>
2023-12-19 21:25:50 +00:00
runs-on: ubuntu-22.04
scx: Add CI action that builds schedulers for PRs When Ubuntu ships with sched_ext, we can also maybe test loading the schedulers (not sure if the runners can run as root though). For now, we should at least have a CI job that lets us verify that the schedulers can _build_. To that end, this patch adds a basic CI action that builds the schedulers. As is, this is a bit brittle in that we're having to manually download and install a few dependencies. I don't see a better way for now without hosting our own runners with our own containers, but that's a bigger investment. For now, hopefully this will get us _some_ coverage. Signed-off-by: David Vernet <void@manifault.com>
2023-12-15 22:07:51 +00:00
steps:
ci: Run CI job on Ubuntu 22.04 Andrea pointed out that we can and should be using Ubuntu 22.04. Unfortunately it still doesn't ship some of the deps we need like clang-17, but it does at least ship virtme-ng, so it's good for us to use this so that we can actually test running the schedulers in a virtme-ng VM when it supports being run in docker. Also, update the job to run on pushes, and not just when a PR is opened Suggested-by: Andrea Righi <andrea.righi@canonical.com> Signed-off-by: David Vernet <void@manifault.com>
2023-12-19 21:25:50 +00:00
### OTHER REPOS ####
# Hard turn-off interactive mode
- run: echo 'debconf debconf/frontend select Noninteractive' | sudo debconf-set-selections
scx: Add CI action that builds schedulers for PRs When Ubuntu ships with sched_ext, we can also maybe test loading the schedulers (not sure if the runners can run as root though). For now, we should at least have a CI job that lets us verify that the schedulers can _build_. To that end, this patch adds a basic CI action that builds the schedulers. As is, this is a bit brittle in that we're having to manually download and install a few dependencies. I don't see a better way for now without hosting our own runners with our own containers, but that's a bigger investment. For now, hopefully this will get us _some_ coverage. Signed-off-by: David Vernet <void@manifault.com>
2023-12-15 22:07:51 +00:00
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
# Refresh packages list
- run: sudo apt update
scx: Add CI action that builds schedulers for PRs When Ubuntu ships with sched_ext, we can also maybe test loading the schedulers (not sure if the runners can run as root though). For now, we should at least have a CI job that lets us verify that the schedulers can _build_. To that end, this patch adds a basic CI action that builds the schedulers. As is, this is a bit brittle in that we're having to manually download and install a few dependencies. I don't see a better way for now without hosting our own runners with our own containers, but that's a bigger investment. For now, hopefully this will get us _some_ coverage. Signed-off-by: David Vernet <void@manifault.com>
2023-12-15 22:07:51 +00:00
### DOWNLOAD AND INSTALL DEPENDENCIES ###
# Download dependencies packaged by Ubuntu
Add stress-ng to scheduler tests This change adds stress-ng as a load test for schedulers when running in CI. It will run stress-ng while schedulers are being tested with a reasonable amount of work. At the end of the run the stress-ng metrics are collected for later analysis. However, since these results may be running in a VM they may not be super robust.
2024-05-17 15:33:15 +01:00
- run: sudo apt -y install bison busybox-static cargo cmake coreutils cpio elfutils file flex gcc gcc-multilib git iproute2 jq kbd kmod libcap-dev libelf-dev libunwind-dev libvirt-clients libzstd-dev linux-headers-generic linux-tools-common linux-tools-generic make ninja-build pahole pkg-config python3-dev python3-pip python3-requests qemu-kvm rsync rustc stress-ng udev zstd
scx: Add CI action that builds schedulers for PRs When Ubuntu ships with sched_ext, we can also maybe test loading the schedulers (not sure if the runners can run as root though). For now, we should at least have a CI job that lets us verify that the schedulers can _build_. To that end, this patch adds a basic CI action that builds the schedulers. As is, this is a bit brittle in that we're having to manually download and install a few dependencies. I don't see a better way for now without hosting our own runners with our own containers, but that's a bigger investment. For now, hopefully this will get us _some_ coverage. Signed-off-by: David Vernet <void@manifault.com>
2023-12-15 22:07:51 +00:00
# clang 17
ci: Run CI job on Ubuntu 22.04 Andrea pointed out that we can and should be using Ubuntu 22.04. Unfortunately it still doesn't ship some of the deps we need like clang-17, but it does at least ship virtme-ng, so it's good for us to use this so that we can actually test running the schedulers in a virtme-ng VM when it supports being run in docker. Also, update the job to run on pushes, and not just when a PR is opened Suggested-by: Andrea Righi <andrea.righi@canonical.com> Signed-off-by: David Vernet <void@manifault.com>
2023-12-19 21:25:50 +00:00
# Use a custom llvm.sh script which includes the -y flag for
# add-apt-repository. Otherwise, the CI job will hang. If and when
# https://github.com/opencollab/llvm-jenkins.debian.net/pull/26 is
# merged, we can go back to using https://apt.llvm.org/llvm.sh.
- run: wget https://raw.githubusercontent.com/Decave/llvm-jenkins.debian.net/fix_llvmsh/llvm.sh
scx: Add CI action that builds schedulers for PRs When Ubuntu ships with sched_ext, we can also maybe test loading the schedulers (not sure if the runners can run as root though). For now, we should at least have a CI job that lets us verify that the schedulers can _build_. To that end, this patch adds a basic CI action that builds the schedulers. As is, this is a bit brittle in that we're having to manually download and install a few dependencies. I don't see a better way for now without hosting our own runners with our own containers, but that's a bigger investment. For now, hopefully this will get us _some_ coverage. Signed-off-by: David Vernet <void@manifault.com>
2023-12-15 22:07:51 +00:00
- run: chmod +x llvm.sh
- run: sudo ./llvm.sh all
- run: sudo ln -sf /usr/bin/clang-17 /usr/bin/clang
- run: sudo ln -sf /usr/bin/llvm-strip-17 /usr/bin/llvm-strip
- uses: actions/checkout@v4
# meson
- run: pip install meson
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
# Install virtme-ng
- run: pip install virtme-ng
ci: Use latest upstream kernel and exclude scx_flatcg and scx_pair from testing
2024-07-15 00:24:59 +01:00
# Get the latest sched-ext enabled kernel directly from the korg
# for-next branch
- run: git clone --single-branch -b for-next --depth 1 https://git.kernel.org/pub/scm/linux/kernel/git/tj/sched_ext.git linux
ci: test the shedulers with the latest sched-ext kernel Instead of downloading a precompiled sched-ext enabled kernel from the Ubuntu ppa, fetch the latest kernel directly from the sched-ext git repository and recompile it on-the-fly using virtme-ng. This allows to get rid of the Ubuntu ppa dependency, take out from the equation potential Ubuntu-specific patches, and ensures testing all the schedulers with the most up-to-date sched-ext kernel (that should also help to detect potential kernel-related issues in advance). The downside is that the CI runs will take a bit longer now, because we are recompiling the kernel from scratch. However, the kernel built with virtme-ng is relatively quick to compile and includes all the sched-ext features required for testing. It's worth noting that this method aligns with the current sched-ext kernel CI, where we test only the in-kernel schedulers (as intended). This change allows to extend the test coverage, using the same kernel to test also the schedulers included in this repository. Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
2024-01-18 08:05:38 +00:00
ci: print the latest commit of the checked out sched-ext kernel Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
2024-01-25 20:18:37 +00:00
# Print the latest commit of the checked out sched-ext kernel
- run: cd linux && git log -1 --pretty=format:"%h %ad %s" --date=short
ci: test the shedulers with the latest sched-ext kernel Instead of downloading a precompiled sched-ext enabled kernel from the Ubuntu ppa, fetch the latest kernel directly from the sched-ext git repository and recompile it on-the-fly using virtme-ng. This allows to get rid of the Ubuntu ppa dependency, take out from the equation potential Ubuntu-specific patches, and ensures testing all the schedulers with the most up-to-date sched-ext kernel (that should also help to detect potential kernel-related issues in advance). The downside is that the CI runs will take a bit longer now, because we are recompiling the kernel from scratch. However, the kernel built with virtme-ng is relatively quick to compile and includes all the sched-ext features required for testing. It's worth noting that this method aligns with the current sched-ext kernel CI, where we test only the in-kernel schedulers (as intended). This change allows to extend the test coverage, using the same kernel to test also the schedulers included in this repository. Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
2024-01-18 08:05:38 +00:00
# Build a minimal kernel (with sched-ext enabled) using virtme-ng
ci: include kernel config chunk The kernel from kernel.org lacks the necessary .config chunk required by the build via virtme-ng. To fix this, include the kernel .config chunk directly in the scx repository and use it from here. Signed-off-by: Andrea Righi <righi.andrea@gmail.com>
2024-07-15 06:10:07 +01:00
- run: cd linux && vng -v --build --config ../.github/workflows/sched-ext.config
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
ci: make sure to use the proper kernel headers Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
2024-04-04 09:44:30 +01:00
# Generate kernel headers
- run: cd linux && make headers
ci: Remove veristat diff workflow The veristat diff action isn't working properly so remove it for now. Instead, run veristat (non diff mode) as part of the build-scheds workflow. This should still provide some useful data for BPF program related stats. Signed-off-by: Daniel Hodges <hodges.daniel.scott@gmail.com>
2024-08-29 13:50:06 +01:00
# veristat
- run: wget https://github.com/libbpf/veristat/releases/download/v0.3.2/veristat-v0.3.2-amd64.tar.gz
- run: tar -xvf veristat-v0.3.2-amd64.tar.gz && sudo cp veristat /usr/bin/
- run: sudo chmod +x /usr/bin/veristat && sudo chmod 755 /usr/bin/veristat
scx: Add CI action that builds schedulers for PRs When Ubuntu ships with sched_ext, we can also maybe test loading the schedulers (not sure if the runners can run as root though). For now, we should at least have a CI job that lets us verify that the schedulers can _build_. To that end, this patch adds a basic CI action that builds the schedulers. As is, this is a bit brittle in that we're having to manually download and install a few dependencies. I don't see a better way for now without hosting our own runners with our own containers, but that's a bigger investment. For now, hopefully this will get us _some_ coverage. Signed-off-by: David Vernet <void@manifault.com>
2023-12-15 22:07:51 +00:00
### END DEPENDENCIES ###
# The actual build:
Add stress-ng to scheduler tests This change adds stress-ng as a load test for schedulers when running in CI. It will run stress-ng while schedulers are being tested with a reasonable amount of work. At the end of the run the stress-ng metrics are collected for later analysis. However, since these results may be running in a VM they may not be super robust.
2024-05-17 15:33:15 +01:00
- run: meson setup build -Dkernel=$(pwd)/linux -Dkernel_headers=./linux/usr/include -Denable_stress=true
ci: mitigate build overload During the build meson attempts to distribute the workload of multiple sub-projects across all available CPUs and parallelize each build within those projects, resulting in an NxN task generation. This process could potentially overload the CI systems, leading to potential failures (see for example issue #202). To mitigate this, always use --jobs=1 during the CI run, which serializes the build of sub-projects and restricts the level of parallelization to N. Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
2024-04-04 09:45:27 +01:00
- run: meson compile -C build --jobs=1
ci: Run CI job on Ubuntu 22.04 Andrea pointed out that we can and should be using Ubuntu 22.04. Unfortunately it still doesn't ship some of the deps we need like clang-17, but it does at least ship virtme-ng, so it's good for us to use this so that we can actually test running the schedulers in a virtme-ng VM when it supports being run in docker. Also, update the job to run on pushes, and not just when a PR is opened Suggested-by: Andrea Righi <andrea.righi@canonical.com> Signed-off-by: David Vernet <void@manifault.com>
2023-12-19 21:25:50 +00:00
ci: test the shedulers with the latest sched-ext kernel Instead of downloading a precompiled sched-ext enabled kernel from the Ubuntu ppa, fetch the latest kernel directly from the sched-ext git repository and recompile it on-the-fly using virtme-ng. This allows to get rid of the Ubuntu ppa dependency, take out from the equation potential Ubuntu-specific patches, and ensures testing all the schedulers with the most up-to-date sched-ext kernel (that should also help to detect potential kernel-related issues in advance). The downside is that the CI runs will take a bit longer now, because we are recompiling the kernel from scratch. However, the kernel built with virtme-ng is relatively quick to compile and includes all the sched-ext features required for testing. It's worth noting that this method aligns with the current sched-ext kernel CI, where we test only the in-kernel schedulers (as intended). This change allows to extend the test coverage, using the same kernel to test also the schedulers included in this repository. Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
2024-01-18 08:05:38 +00:00
# Print CPU model before running the tests (this can be useful for
# debugging purposes)
- run: grep 'model name' /proc/cpuinfo | head -1
ci: enable kvm support in the github workflow Enable kvm acceleration and qemu microvm to speed up CI tests inside virtme-ng. Also adjust the regex to catch potential errors excluding a false positive triggered by the new configuration. Link: https://github.blog/changelog/2023-02-23-hardware-accelerated-android-virtualization-on-actions-windows-and-linux-larger-hosted-runners/ Link: https://github.blog/2024-01-17-github-hosted-runners-double-the-power-for-open-source/ Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
2024-05-03 22:20:10 +01:00
# Setup KVM support
- run: |
echo 'KERNEL=="kvm", GROUP="kvm", MODE="0666", OPTIONS+="static_node=kvm"' | sudo tee /etc/udev/rules.d/99-kvm4all.rules
sudo udevadm control --reload-rules
sudo udevadm trigger --name-match=kvm
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
# Test schedulers
- run: meson compile -C build test_sched
Add stress-ng to scheduler tests This change adds stress-ng as a load test for schedulers when running in CI. It will run stress-ng while schedulers are being tested with a reasonable amount of work. At the end of the run the stress-ng metrics are collected for later analysis. However, since these results may be running in a VM they may not be super robust.
2024-05-17 15:33:15 +01:00
# Stress schedulers
- run: meson compile -C build stress_tests
ci: Remove veristat diff workflow The veristat diff action isn't working properly so remove it for now. Instead, run veristat (non diff mode) as part of the build-scheds workflow. This should still provide some useful data for BPF program related stats. Signed-off-by: Daniel Hodges <hodges.daniel.scott@gmail.com>
2024-08-29 13:50:06 +01:00
- run: meson compile -C build veristat
Reference in New Issue Copy Permalink