Module latency 

Latency histograms (plan.md Phase 12).

Four fixed-size, zero-allocation histograms — 16 log2-scaled buckets each ([AtomicU32; 16]), bucket b covers [2^b, 2^(b+1)) cycles (bucket 0 covers 0-1) — tracking:

• Kind::IrqEntry: cycles from an interrupt firing to crate::preempt::on_tick actually running. Recorded by the arch trap entry (whichever rivet-arch-* crate captures a cycle stamp as early as possible in the handler).
• Kind::DispatchDecision: cycles spent inside on_tick itself — the scheduling decision’s own cost.
• Kind::CriticalSection: cycles held between crate::critical::enter’s entry and exit — a proxy for interrupt-latency impact (nothing can preempt the calling hart while held).
• Kind::SchedulingWake: cycles from a task becoming ready (sched::unblock / ready_add) to actually being dispatched Running.

Gated behind the latency-histograms feature (off by default — see rivet/Cargo.toml): recording a sample is one cycle_count() read plus one atomic increment, cheap but not free, and a cost-sensitive board that never reads the histograms shouldn’t pay it unasked.

Enums

Kind

Constants

ALL_KINDS

BUCKETS

Functions

max_cycles

Exact worst-case-observed cycle count for kind (0 if never recorded) — see [MAX_CYCLES]’s own doc for why this exists alongside the bucketed histogram.

name

Human-readable name, for report().

record

See the feature-gated record above; a no-op stub keeps call sites (arch crates, on_tick, critical::enter, sched::unblock) free of #[cfg] clutter when the feature is off.

snapshot

Snapshot of one histogram’s 16 bucket counts.