Isolation, Scale, and the Boundary of Better Telemetry

NEMO's tiering results show what a matched signal can enable; this chapter asks what happens when the policy must run continuously under interference and finite hardware resources. The noisy-neighbor experiment separates measurement accuracy from reaction and actuation cost, while the scaling and security analysis shows where controller-side telemetry stops being a universal answer. The useful judgment is not whether NEMO is “fast,” but which part of the control loop it improves and what the prototype still leaves unresolved.

A noisy neighbor is a control-loop problem

A noisy neighbor is a tenant whose memory activity consumes enough shared bandwidth to harm another tenant's service. The symptom appears at the victim: tail latency rises. The cause is not necessarily an inaccurate placement decision; it may be a background task issuing bursts of memory traffic. The operator therefore needs three linked capabilities: attribute bandwidth to the responsible tenant, detect a violation quickly, and actuate a limit before the victim's service suffers for too long.

NEMO configures that view as a many-to-one mapping. All huge pages belonging to a tenant contribute to one telemetry state, and each observed access increments the state. The OS or a userspace controller reads the tenant's count, computes bandwidth over an interval, and adjusts the tenant's Linux cgroup CPU quota toward a target. A threshold predicate can signal that the tenant has crossed its allocation. This is a different mapping from HeMem's one-counter-per-page view, but it uses the same controller-side ability to attribute many physical regions to a policy owner.

The comparison baseline is Intel Memory Bandwidth Monitoring, or MBM. In the isolated bandwidth test, both NEMO and MBM report values within 0.1% of a ground truth estimated from the volume of non-temporal stores. That result matters because it rules out a simple explanation in which NEMO wins only by measuring bandwidth more accurately. Both instruments can produce a close estimate in this workload. The difference emerges when the controller must obtain the estimate often enough to react.

stateDiagram-v2 [*] --> Normal Normal --> Overloaded: Noisy neighbor bursts Overloaded --> Measured: NEMO threshold or MBM poll Measured --> Throttled: Controller adjusts cgroup quota Throttled --> Normal: Actuation takes effect Measured --> Overloaded: Polling or actuation is late

With no throttling, the noisy neighbor increases FlexKVS p99 latency by about 22%. When NEMO drives the controller, the increase falls to 5.2%; MBM reaches a similar 5.5% increase under the tested configuration. The mitigation is therefore comparable in effect. The important difference is the CPU budget required to acquire the signal at the needed cadence.

At a 1 ms MBM polling interval, the baseline consumes 32% of a core while achieving the faster reaction. At 100 ms, it consumes only 0.7% of a core, but the slower response leaves a 13% p99 increase. NEMO achieves comparable mitigation with 0.09% CPU overhead in the reported experiment.