Intel CAT lets you partition L3 capacity, but capacity isn't the only shared resource — the path from L3 to DRAM is a single fat pipe that every core fights over. A batch job doing a linear scan can saturate the memory controller and starve a latency-sensitive service sharing the socket. Memory Bandwidth Allocation (MBA) is the sibling feature that throttles how much of that pipe each workload gets.

MBA works differently than you'd expect. It doesn't measure bytes and cap them directly — it inserts delay cycles between memory requests from a given class of service (CLOS). You configure a throttle value from 10 to 100 (in steps of 10 on Skylake, finer on later parts), where 100 means "no throttle" and 10 means "insert maximum delay between L2 misses." The throttle is applied at the L2 miss point, before the request even reaches the L3 or the mesh.

The mechanism is indirect and non-linear. Setting a CLOS to 50% doesn't guarantee 50% of bandwidth — it guarantees the request rate is halved, and actual bandwidth depends on how many outstanding misses that workload can generate, the latency of each miss, and what other CLOSes are doing. If nobody else is competing, a throttled workload still gets most of the bandwidth because the pipe is idle.

Real-world example: A cloud provider colocates a Redis instance (latency-critical, small working set) with a Spark executor (bandwidth-hungry, streaming through gigabytes) on the same socket. Without MBA, Spark's linear scans push Redis's tail latency from 200µs to 2ms because the memory controller queue fills with Spark's requests. The provider assigns Spark to CLOS 2 with MBA throttle 30, and Redis to CLOS 1 with throttle 100. Spark's throughput drops ~15%, but Redis's p99 returns to 250µs. The throughput/latency tradeoff is explicit and tunable.

Rule of thumb: MBA throttle values behave roughly like a soft priority scheme. If your latency-critical workload has p99 spikes correlated with a noisy neighbor's memory activity, start by throttling the neighbor to 50 and measure — halving isn't halving, but it usually cuts contention enough to see whether MBA is the right lever.

MBA is configured via the same resctrl filesystem as CAT on Linux (/sys/fs/resctrl/), and the two features compose: you can pin a workload to specific L3 ways and throttle its DRAM bandwidth in the same CLOS. Later generations (Ice Lake+) added MBA 2.0, which reports actual bandwidth consumed per CLOS via monitoring counters, letting you close the loop and adjust throttles based on measured contention instead of guessing.