scx_stat is a statistics reporting library with the following goals:
- Minimal boilerplate code. Statistics are defined as a regular rust struct
which can contain integers, floats, strings, structs, and array or
BTreeMap of them. The struct and each field can be annotated using the
"stat" attribute. The "Stat" derive macro generates the necessary
metadata.
- On-demand reporting. ScxStatServer implements a UNIX domain socket server
which communicates using a simple json protocol. Stat structs can be added
to the server with closures to output them. There can be any number of
readers. ScxStatServer can be queried for the metadata of all stat structs
that it may report so that a generic tool can be written to pipe the
reported statistics to other frameworks (e.g. openmetrics).
- The interface protocol is pretty simple and it isn't difficult to interact
directly in json. ScxStatClient is provided to further simplify client
implementation.
- See rust/scx_stat/examples/{server,client}.rs for usage.
Introduce a separate crate (scx_rustland_core) that can be used to
implement sched-ext schedulers in Rust that run in user-space.
This commit only provides the basic layout for the new crate and the
abstraction to the custom allocator.
In general, any scheduler that has a user-space component needs to use
the custom allocator to prevent potential deadlock conditions, caused by
page faults (a kthread needs to run to resolve the page fault, but the
scheduler is blocked waiting for the user-space page fault to be
resolved => deadlock).
However, we don't want to necessarily enforce this constraint to all the
existing Rust schedulers, some of them may do all user-space allocations
in safe paths, hence the separate scx_rustland_core crate.
Merging this code in scx_utils would force all the Rust schedulers to
use the custom allocator.
In a future commit the scx_rustland backend will be moved to
scx_rustland_core, making it a totally generic BPF scheduler framework
that can be used to implement user-space schedulers in Rust.
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
