scx/scheds/rust/scx_rusty
Andrea Righi d76551bbd3 scx_rusty: fix stats map initialization
The stats map in scx_rusty is a BPF_MAP_TYPE_PERCPU_ARRAY, with its size
determined by num_possible_cpus(). Initializing it with nr_cpu_ids() can
result in errors such as:

 Error: Failed to zero stat

 Caused by:
     number of values 6 != number of cpus 8

Fix by using num_possible_cpus() to initialize it.

Fixes: 263e02f6 ("rusty: Use nr_cpu_ids instead of nr_cpus_possible")
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
2024-06-30 17:37:14 +02:00
..
src scx_rusty: fix stats map initialization 2024-06-30 17:37:14 +02:00
.gitignore Restructure scheds folder names 2023-12-17 13:14:31 -08:00
build.rs Restructure scheds folder names 2023-12-17 13:14:31 -08:00
Cargo.toml rusty: Integrate stats with the metrics framework 2024-06-21 10:18:44 -06:00
LICENSE Restructure scheds folder names 2023-12-17 13:14:31 -08:00
meson.build meson: introduce serialize build option 2024-06-28 10:17:37 +02:00
README.md Add README files for each rust scheduler 2024-01-04 07:35:44 -08:00
rustfmt.toml Restructure scheds folder names 2023-12-17 13:14:31 -08:00

scx_rusty

This is a single user-defined scheduler used within sched_ext, which is a Linux kernel feature which enables implementing kernel thread schedulers in BPF and dynamically loading them. Read more about sched_ext.

Overview

A multi-domain, BPF / user space hybrid scheduler. The BPF portion of the scheduler does a simple round robin in each domain, and the user space portion (written in Rust) calculates the load factor of each domain, and informs BPF of how tasks should be load balanced accordingly.

How To Install

Available as a Rust crate: cargo add scx_rusty

Typical Use Case

Rusty is designed to be flexible, and accommodate different architectures and workloads. Various load balancing thresholds (e.g. greediness, frequenty, etc), as well as how Rusty should partition the system into scheduling domains, can be tuned to achieve the optimal configuration for any given system or workload.

Production Ready?

Yes. If tuned correctly, rusty should be performant across various CPU architectures and workloads. Rusty by default creates a separate scheduling domain per-LLC, so its default configuration may be performant as well. Note however that scx_rusty does not yet disambiguate between LLCs in different NUMA nodes, so it may perform better on multi-CCX machines where all the LLCs share the same socket, as opposed to multi-socket machines.

Note as well that you may run into an issue with infeasible weights, where a task with a very high weight may cause the scheduler to incorrectly leave cores idle because it thinks they're necessary to accommodate the compute for a single task. This can also happen in CFS, and should soon be addressed for scx_rusty.