hw-model

Workload-mode detector (Phase 1)

One LightGBM multiclass booster, 32 iterations × 5 classes = 160 trees, max 8 leaves each, depth ≤ 4. Trained on three independent 30-second fio sessions per workload class, group-stratified by session_id so no within-run autocorrelation leaks. Forbidden-leakage column list (PID, process_name, command, path, filename, host_id) dropped at training time.

Per-class performance on the held-out fold

Top features by gain

Why these features and not others

Byte features dominate after the BPF-side bug fix that made sys_exit.ret readable. avg_read_size and avg_write_size went from 0 gain (with the bug) to top-4 (without). Pure count features (pread64_count, pwrite64_count) are still the largest contributors, since count rate already separates random from sequential workloads (random has 4× the IOPS at the same fio rate cap). Burstiness collapsed from rank #3 to rank #13 once entry-side tracepoints made every syscall fire both an sys_enter_* and raw_syscalls/sys_exit event — the within-pair gap dominates the between-syscall gap, and burstiness becomes uninformative. That is a real characteristic of the new event stream, not a regression.

Honest split rules

Confidence calibration (Phase 5)

LightGBM's multiclass softmax is roughly the right shape but is not honestly probabilistic. A diagnostic on the 4412-row dataset showed mean confidence 0.880 vs actual accuracy 0.965 — the model was systematically under-confident. Thresholding the raw softmax at 0.80 was therefore rejecting many windows the model was actually certain about, which made idle sessions emit only 0.27–0.83 of the time even though they were classified correctly.

Temperature scaling fits a single scalar T

From Guo et al. 2017: choose T > 0 minimising negative log-likelihood of softmax(logits / T) on a held-out calibration set. T < 1 sharpens an under-confident model; T > 1 softens an over-confident one. Crucially, temperature scaling preserves the argmax, so top-1 prediction is unchanged after calibration — only the distribution over classes is rescaled.

Result on the 32 / 8 / 4 model, calibration set = held-out test fold (1471 rows)

Behavioural impact: idle sessions emit a stable mode

With the same hysteresis settings (5-window stable, 0.80 confidence, 0.20 margin), idle session emit-rate jumps:

Compile to runtime-free C (Phase 6)

The trained booster is reduced to plain C. No LightGBM runtime, no Python at inference time, only expf() from <math.h> for the softmax confidence. Each tree compiles to a static-inline function returning a leaf value via nested ternary; the top-level workload_predict_*() sums per-class scores and runs argmax + numerically-stable softmax.

Two paths from the same booster

Bake-in: temperature, quantization, calibration

Every constant used at runtime is generated from the trained model:

/* workload_model.h header (excerpt) */
#define WORKLOAD_NUM_FEATURES     36
#define WORKLOAD_NUM_CLASSES      5
#define WORKLOAD_TEMPERATURE      0.673289829f
#define WORKLOAD_INV_TEMPERATURE  1.48524448f

/* per-feature offset/scale arrays for Q15 quantization, derived from
 * LightGBM feature_infos with a 5% headroom margin */
extern const float workload_feature_offset[WORKLOAD_NUM_FEATURES];
extern const float workload_feature_scale[WORKLOAD_NUM_FEATURES];

void workload_quantize(const float features[], int16_t q[]);
workload_prediction_t workload_predict_float(const float features[]);
workload_prediction_t workload_predict_fixed(const int16_t q[]);

Parity gate (1466 rows of 5 distinct workloads)

Cortex-M ROM at -Os (Phase 7 cross-compile)

Cross-compiled with arm-none-eabi-gcc 15.2.1, full optimisation for size, -ffunction-sections + -fdata-sections. The model + frame protocol live in .text; no .bss, no .data beyond the per-class label name strings.

Per-target footprint

Frame-protocol layer adds (workload_frame.o only)

Total fixed-only deployment cost

Real-chip inference latency (Phase 7 A53)

The eighth and final §1.4 confidence gate: "can the predictor actually run fast enough on real silicon?" Measured on a Kria KV260 Vision AI Starter Kit (Zynq UltraScale+ MPSoC, Cortex-A53 @ 1.333 GHz), fresh Canonical Limerick image, gcc 13.3 aarch64, -O2. SCHED_FIFO + taskset -c 0 + scaling_governor=performance. 5000 iterations × 1466 feature rows = 7.33 M calls per path.

Per-call latency distribution

Why fixed is faster

Both paths execute the same number of compares and the same softmax. The difference is that integer compares fuse into a single ARM CMP + branch, while float compares require FCMP through the FPU. Because the trees themselves contain no FP arithmetic to do, the FPU is idle on the float path — it only adds latency.

Cross-architecture reference (prune x86_64, gcc 13.3, -O2)

A53 path is ~36× slower than x86_64 in absolute time. A53 is in-order dual-issue; modern out-of-order x86 has wider pipelines, larger TLB, faster L1. The interesting fact is not the ratio — it's that both clear the §1.4 wall-clock budget by orders of magnitude.

Policy simulator (Phase 9)

Read-only by design. Runs the calibrated detector + the policy mapping in labels.yaml against every 100 ms feature window and records what an actuator would have applied. Never opens, writes, or ioctls a kernel knob. The point is to characterise the detector + actuator pair before granting the actuator write permission to /sys — the empirical foundation for the actuator gates in MICROCONTROLLER_AND_ACTUATOR.md §2.3.

Failure-mode matrix — the part that matters

Policy mapping (from labels.yaml)

USB-CDC frame protocol (Phase 7 frame)

The host aggregates eBPF events, runs the feature aggregator, and sends the device one quantized feature row every 100 ms. The device runs workload_predict_fixed() and replies with a prediction frame. Same wire format works for the MCU PoC and (later) the FPGA-fabric path.

Feature frame (host → device, 90 bytes for 36 features)

typedef struct __attribute__((packed)) {
    uint32_t magic;            /* WLDM = 0x4D444C57 little-endian */
    uint32_t seq;              /* monotonic, host-side */
    uint16_t version;
    uint16_t window_ms;
    uint16_t feature_count;    /* must equal WORKLOAD_NUM_FEATURES */
    int16_t  features_q[36];   /* Q15 quantized */
    uint32_t crc32;            /* CRC-32/IEEE-802.3 over preceding bytes */
} workload_feature_frame_t;

Prediction frame (device → host, 24 bytes)

typedef struct __attribute__((packed)) {
    uint32_t magic;
    uint32_t seq;              /* echoes feature.seq */
    uint16_t version;
    uint16_t predicted_class;  /* raw top-1, no hysteresis */
    uint16_t stable_class;     /* post-hysteresis or 0xFFFF unknown */
    uint16_t confidence_q15;
    uint16_t margin_q15;
    uint8_t  reserved[2];
    uint32_t crc32;
} workload_prediction_frame_t;

Bit-flip fuzz results

Where this scales

The methodology is portable. Same discipline that produced the storage workload classifier in workload_predict_fixed() can produce other small learned policies that today live inside a GPU's hot path or inside an SSD's controller, and move them out of those paths.

Storage path (the original thesis)

Transformer-side path (the bigger play)

Three concrete PoCs ranked by tractability, from MICROCONTROLLER_AND_ACTUATOR.md §3.3–3.5:

Confidence checklist for any actuator (from MICROCONTROLLER_AND_ACTUATOR.md §2.3)

First actuator candidate: read_ahead_kb

Per-block-device /sys/block/<dev>/queue/read_ahead_kb. Reversible, durability-neutral, observable via iostat, costs cache bandwidth not consistency on miclassification. Right first knob to learn the actuator-side discipline before touching anything that affects barriers, fsync, or write paths.