JakeHillion/scx
1
0
Fork 0
mirror of https://github.com/JakeHillion/scx.git synced 2024-11-27 03:40:23 +00:00
Code Issues Packages Projects Releases Wiki Activity
a3b5941c3a
scx/.github/workflows/build-scheds.yml

73 lines
3.0 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: 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
on: [pull_request, push]
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
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
- run: sudo apt -y install bison busybox-static cargo cmake coreutils cpio elfutils file flex gcc git iproute2 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 python3-dev python3-pip python3-requests qemu-kvm rsync rustc 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
# bpftool
- run: git clone --recurse-submodules --branch v7.3.0 https://github.com/libbpf/bpftool.git
- run: make -j -C bpftool/src
- run: sudo make -j -C bpftool/src install
- uses: actions/checkout@v4
# libbpf
- run: git clone --recurse-submodules --branch v1.3.0 https://github.com/libbpf/libbpf.git
- run: make -j -C libbpf/src
- run: sudo make -j -C libbpf/src install
# 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: 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
# Get the latest sched-ext enabled kernel directly from the git
# repository (try the sched_ext-ci branch first, if it doesn't exist use
# sched_ext)
- run: git clone --single-branch -b sched_ext-ci --depth 1 https://github.com/sched-ext/sched_ext.git linux || git clone --single-branch -b sched_ext --depth 1 https://github.com/sched-ext/sched_ext.git linux
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
- 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
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:
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
- run: meson setup build -Dlibbpf_a=`pwd`/libbpf/src/libbpf.a -Dkernel=$(pwd)/linux
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: meson compile -C build
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: 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
Reference in New Issue Copy Permalink