Module queues 

The per-CID queues, observed from the loader. The arena the BPF program keeps them in is mapped into this process too, at the addresses the program itself uses, so the loader reads a queue through the same edq code the program runs, over a memory that can only load.

Nothing is added to the scheduling paths for this. A queue already counts the tasks it holds and the tasks ever queued on it, and both are read without its lock. The time a task waits in a queue follows from the two: by Little’s law the average wait is the average depth over the arrival rate. The arrivals are exact, and the depth is sampled by a thread that runs only while a stats client is polling.

Re-exports

use std::ffi::OsStr; 🔒

use std::sync::Arc; 🔒

use std::sync::Mutex; 🔒

use std::sync::atomic::AtomicBool; 🔒

use std::sync::atomic::AtomicU64; 🔒

use std::sync::atomic::Ordering; 🔒

use std::thread; 🔒

use std::time::Duration; 🔒

use std::time::Instant; 🔒

use anyhow::Context; 🔒

use anyhow::Result; 🔒

use anyhow::ensure; 🔒

use libbpf_rs::AsRawLibbpf; 🔒

use libbpf_rs::MapCore; 🔒

use libbpf_rs::MapFlags; 🔒

use crate::Loaded; 🔒

use crate::OpsProfiler; 🔒

use crate::edq; 🔒

use crate::edq::View; 🔒

Structs

ArenaView

The arena, read through the mapping libbpf made when it created the map. The addresses the BPF program stores are user addresses in that mapping, so they are read as they are. An address outside of it reads as 0. The view keeps the object, and with it the mapping, alive.

CidTableReader

A per-CID table of the scheduler’s, read from the loader: the one whose header is in the .data section section, see scx_rustsched’s cid_slot!, with words 64-bit words per CID. For counters each CPU keeps for itself, which cost the scheduling paths no shared write.

QueueSampler

Samples the depth of every CID’s queue while a stats client is polling, and parks once nobody has asked for a while, as the callback profiler drops its accounting.

QueueStats

What the sampler saw of one CID’s queue, cumulative.

Shared 🔒

State 🔒