You've seen CAT (cache partitioning) and MBA (bandwidth throttling). Both need a prerequisite: knowing who's actually using the bandwidth. That's MBM — the read-only telemetry layer of Intel's Resource Director Technology (RDT). Without it, throttling is guesswork.

MBM works by tagging every L3 miss with an RMID (Resource Monitoring ID) assigned to the running thread via IA32_PQR_ASSOC MSR. When a miss escapes L3 and hits the memory controller, hardware increments a per-RMID counter in the uncore. Two counters exist per RMID:

• Total bandwidth — every L3 miss, including prefetches and coherence traffic pulled from remote sockets.
• Local bandwidth — only misses satisfied by the DRAM attached to this socket. Subtracting gives you cross-socket NUMA traffic for free.

Software reads these via IA32_QM_CTR after selecting the RMID+event through IA32_QM_EVTSEL. Linux exposes it through the resctrl filesystem — you echo a PID into /sys/fs/resctrl/mon_groups/foo/tasks and then cat mon_data/mon_L3_00/mbm_total_bytes.

Concrete example: a Redis instance and a batch analytics job share a 28-core Xeon. Latency on Redis spikes intermittently. Perf counters show low IPC but no obvious cache misses at L1/L2. You create two resctrl monitor groups, assign Redis to one and the analytics job to the other, and watch mbm_total_bytes over 10 seconds. Redis: 400 MB/s. Analytics: 38 GB/s — saturating the ~45 GB/s DDR4 channel budget. Now you know the analytics job is the noisy neighbor, so you apply MBA to cap it at 60% bandwidth. Redis p99 drops from 12ms to 800µs.

The catch with counters: RMIDs are a finite hardware resource — typically 128 or 256 per socket. If you have more cgroups than RMIDs, resctrl multiplexes them, and readings become sampled rather than continuous. Also, the counters are event-count-based, not byte-precise: each increment represents a cache-line-sized transfer (64 bytes), so short bursts under one line get rounded.

Rule of thumb: if MBM shows a workload sustaining more than ~70% of your theoretical DRAM bandwidth (channels × transfer rate × 8 bytes), latency-sensitive co-tenants will suffer, because DRAM queueing delay explodes non-linearly past that point. That's the trigger to reach for MBA.

MBM is the "before" measurement that makes every other RDT knob defensible. Throttle without it and you're flying blind.