scx/scheds/rust/meson.build

32 lines
1.2 KiB
Meson
Raw Normal View History

# the previous scheduler in the compile sequence
sched = []
# Since meson and cargo tries build in parallel, this can cause significant load
# when meson tries to launch N instances of cargo and cargo tries to compile N files
# in parallel (N*N compiler instances in total).
#
# To prevent this from happening, we try to force meson to build them sequentially
# by making the "current" scheduler depend on another scheduler.
# To add a new scheduler, assign the output of your custom_target to sched
# and add sched as a dependency to your custom_target. For example:
#
# sched = custom_target('scx_mysched',
# ...
# depends: [mydep, sched],
# build_always_stale: true)
subdir('scx_layered')
#subdir('scx_mitosis') # Temporarily excluded until cgroup support lands in the kernel
subdir('scx_rusty')
subdir('scx_rustland')
subdir('scx_rlfifo')
scheds: introduce scx_bpfland Overview ======== This scheduler is derived from scx_rustland, but it is fully implemented in BFP with minimal user-space Rust part to process command line options, collect metrics and logs out scheduling statistics. Unlike scx_rustland, all scheduling decisions are made by the BPF component. Motivation ========== The primary goal of this scheduler is to act as a performance baseline for comparison with scx_rustland, allowing for a better assessment of the overhead caused by kernel/user-space interactions. It can also be used to deploy prototypes initially tested in the scx_rustland scheduler. In fact, this scheduler is expected to outperform scx_rustland, due to the elimitation of the kernel/user-space overhead. Scheduling policy ================= scx_bpfland is a vruntime-based sched_ext scheduler that prioritizes interactive workloads. Its scheduling policy closely mirrors scx_rustland, but it has been re-implemented in BPF with some small adjustments. Tasks are categorized as either interactive or regular based on their average rate of voluntary context switches per second: tasks that exceed a specific voluntary context switch threshold are classified as interactive. Interactive tasks are prioritized in a higher-priority DSQ, while regular tasks are placed in a lower-priority DSQ. Within each queue, tasks are sorted based on their weighted runtime, using the built-in scx vtime ordering capabilities (scx_bpf_dispatch_vtime()). Moreover, each task gets a time slice budget. When a task is dispatched, it receives a time slice equivalent to the remaining unused portion of its previously allocated time slice (with a minimum threshold applied). This gives latency-sensitive workloads more chances to exceed their time slice when needed to perform short bursts of CPU activity without being interrupted (i.e., real-time audio encoding / decoding workloads). Results ======= According to the initial test results, using the same benchmark "playing a videogame while recompiling the kernel", this scheduler seems to provide a +5% improvement in the frames-per-second (fps) compared to scx_rustland, with video games such as Cyberpunk 2077, Counter-Strike 2 and Baldur's Gate 3. Initial test results indicate that this scheduler offers around a +5% improvement in frames-per-second (fps) compared to scx_rustland when using the benchmark "playing a video game while recompiling the kernel". This improvement was observed in games such as Cyberpunk 2077, Counter-Strike 2, and Baldur's Gate 3. Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
2024-06-24 06:56:03 +01:00
subdir('scx_bpfland')
subdir('scx_lavd')
# the target to compile all rust schedulers
custom_target('rust_scheds',
input: 'meson.build',
output: '@PLAINNAME@.__PHONY__',
command: ['touch', '@PLAINNAME@.__PHONY__'],
depends: sched,
build_by_default: true)