Expand description
Scenario definitions and test execution.
Most tests use the declarative ops API from the ops submodule:
ops::CgroupDef– declarative cgroup definition (name + cpuset + workload)ops::Step– a sequence of ops followed by a hold periodops::Op– an atomic scenario operation (cgroup/worker topology, payload run/wait/kill, freeze, snapshot, kernel read/write, scheduler attach/detach/restart/replace, BPF map pin)ops::CpusetSpec– how to compute a cpuset from topologyops::HoldSpec– how long to hold after a stepbackdrop::Backdrop– persistent scenario state shared across every Stepops::execute_defs– run cgroup definitions for the full durationops::execute_steps– run a multi-step sequenceops::execute_scenario– run a Backdrop + Steps sequence
Types defined in this module:
Ctx– runtime context passed to scenario functionsCgroupGroup– RAII guard that removes cgroups on drop
The scenarios submodule provides curated canned scenarios.
§Builder method conventions
Every builder type in the scenario API (Setup, Step, Backdrop, WorkloadConfig, …) names its methods by what they do, not by what they return. The three-prefix vocabulary is uniform across the scenario surface so a reader can predict semantics from the prefix alone:
with_X(arg) -> Self— alternate constructor that returns a fresh value withXalready set (e.g.ops::Step::with_defs,ops::Step::with_payload,ops::Setup::with_factory). Distinct fromSelf::new(...)which is the base ctor;with_Xconstructors compose without reaching forDefault::default()then chaining setters.set_X(self, value) -> Self— field REPLACE on an existing builder. Consumesself, writesX, returns the updated value (e.g.ops::Step::set_ops,ops::Step::set_hold). Previous contents ofXare discarded.push_X(self, value) -> Self/extend_X<I>(self, iter) -> Self— field APPEND.push_Xadds one element,extend_Xadds many from anyIntoIterator(e.g.backdrop::Backdrop::push_cgroup/backdrop::Backdrop::extend_cgroups).
Naming an APPEND method set_X (or a REPLACE method push_X)
mis-encodes the semantics and is a defect — flag at review.
See the Scenarios and Writing Tests chapters of the guide.
Re-exports§
pub use backdrop::Backdrop;pub use crate::workload::AffinityIntent;
Modules§
- affinity
- CPU affinity scenario implementations.
- backdrop
- Persistent scenario state that lives across every Step in a
#[ktstr_test]run. - basic
- Basic and mixed-workload scenario implementations.
- bpf_pin
- Guest-side BPF map fd pinning. See
crate::scenario::ops::Op::PinBpfMapfor the full motivation; in short, the same-binaryOp::ReplaceSchedulerswap window’s multi-bss case (two<obj>.bsscopies coexisting while the dying scheduler’s BPF object is being torn down) only fires when both copies are still alive at freeze time, and the kernel frees the dying instance’s maps as soon as libbpf drops their fds. Holding an extra refcount via this helper keeps the dying scheduler’s map alive long enough for at least one post-swap freeze to observe both copies, which is what the framework’scrate::scenario::snapshot::Snapshot::activeplus walker disambiguation chain exists to handle. - cpuset
- Cpuset mutation scenario implementations.
- dynamic
- Dynamic cgroup add/remove scenario implementations.
- host_
stall - Host-mode worker stall detection via
/proc/<pid>/schedpolling. - interaction
- Cross-cgroup interaction scenario implementations.
- nested
- Nested cgroup hierarchy scenario implementations.
- ops
- Composable ops/steps system for dynamic cgroup topology changes.
- payload_
run - Runtime builder for launching a
Payloadfrom a test body. - performance
- Performance and benchmarking scenario implementations.
- sample
- Unified periodic-sample bundle and series projection.
- scenarios
- Curated canned scenarios for common scheduler test patterns.
- snapshot
- Diagnostic snapshot capture and traversal.
- stress
- Stress and edge-case scenario implementations.
Structs§
- Cgroup
Group - RAII guard that removes cgroups on drop.
- Ctx
- Runtime context passed to scenario functions.
- CtxBuilder
- Fluent builder for
Ctx.
Functions§
- collect_
all - Stop all workers, collect reports, and run assertion checks.
- dfl_wl
- Default
WorkloadConfigwithctx.workers_per_cgroupworkers. - resolve_
affinity_ for_ cgroup - Resolve an
AffinityIntentto a concreteResolvedAffinityfor workers in a cgroup with the given effective cpuset. - setup_
cgroups - Create N cgroups, spawn workers in each, and start them.
- spawn_
diverse - Spawn diverse workloads across N cgroups: SpinWait, Bursty,
IoSyncWrite, Mixed, YieldHeavy. Each cgroup uses
ctx.workers_per_cgroupworkers except IoSyncWrite cgroups, which always use 2 workers to avoid drowning the scenario in blocking IO.