Unit 13 · Cloud research · Lesson 2 of 5
Interference, noisy neighbors and performance isolation
Step 1: Learn the ideas
- Shared resources: cores and hyperthreads, last-level cache, memory bandwidth, NUMA, network, disk, kernel
- Sensitivity versus pressure (contentiousness)
- Tail amplification through queueing and fan-out
- Linux cgroup v2 controllers: cpu, cpuset, memory, io
- CPU pinning, the Kubernetes static CPU manager policy and QoS classes
- Cache allocation and memory-bandwidth allocation (resctrl)
- VMs and microVMs: isolation boundary versus shared hardware
- Interference-aware management: Heracles, CPI-based detection
- Measurement pitfalls in co-location experiments
Why it matters
Co-locating workloads raises utilization, but co-located workloads interfere through shared caches, memory bandwidth, CPU scheduling, network and storage. The damage appears first in the tail latency of latency-critical services, not in averages. Explaining the mechanisms, the isolation tools and how to measure interference credibly is central to cloud systems research, and it maps directly onto experiments such as memcached under co-location.
Core ideas
Where interference comes from.
- CPU time: runnable threads wait for a core (scheduling delay), and CPU quotas can throttle a container in bursts.
- Simultaneous multithreading: sibling hyperthreads share execution units and private caches.
- Last-level cache: a cache-hungry neighbor evicts your working set, turning hits into memory accesses.
- Memory bandwidth: saturated memory controllers raise latency for everyone on the socket; NUMA adds remote-access penalties.
- Network and storage: shared NIC queues, switch buffers and device queues add queueing delay.
- Kernel and power: shared locks, interrupt processing, page-cache pressure, and frequency changes under power or thermal limits.
Sensitivity and pressure. A workload is sensitive to a resource if it slows down when that resource is contended, and it exerts pressure if it slows others. Measure both per resource with microbenchmarks that stress one resource at a time.
Why tails move first. Latency-critical services run at moderate utilization because queueing delay grows sharply near saturation. Interference raises service time and its variance, which raises effective utilization and moves p95 and p99 long before the median. Fan-out amplifies this: a request that waits for many backends sees the tail of each one.
Isolation mechanisms and their gaps.
- cgroup v2 cpu.weight and cpu.max share or cap CPU time but partition neither caches nor memory bandwidth, and hard caps can add throttling stalls.
- cpusets and pinning give dedicated cores; Kubernetes' static CPU manager policy gives exclusive cores to Guaranteed pods with integer CPU requests. Pinned cores still share the last-level cache and memory controllers, and sibling hyperthreads share more.
- Cache allocation and memory-bandwidth allocation (Linux resctrl, on supporting hardware) partition the last-level cache and throttle bandwidth per group.
- memory.max limits capacity, not bandwidth; io.max limits block I/O; traffic control or virtual-device rate limiters, as in Firecracker, bound network and disk use.
- VMs and microVMs separate kernels and strengthen security isolation but share the same physical caches, memory bandwidth and devices, so performance interference and side channels need further measures such as disabling SMT or partitioning.
Interference-aware management. Heracles co-locates best-effort tasks with a latency-critical service and runs a feedback controller over cores, cache partitions, memory bandwidth, network and power, driven by the service's latency slack. CPI² detects victims from cycles-per-instruction outliers and throttles suspected antagonists. Leverich and Kozyrakis attribute memcached quality-of-service violations under co-location to queueing delay, scheduling delay and thread load imbalance, and test mitigations.
Measuring credibly. Fix the service's configuration, use an open-loop load generator, sweep load, add one antagonist at a time with controlled intensity and placement (sibling hyperthread, other core, other socket), repeat runs, and record hardware counters such as cache misses and memory bandwidth. Control or at least record frequency scaling and SMT.
Common misconceptions
- "Containers with CPU limits are isolated." CPU quotas partition neither caches nor memory bandwidth, and throttling can create latency spikes of its own.
- "VMs eliminate noisy neighbors." They isolate software state, not shared hardware; microarchitectural interference remains without partitioning.
- "Interference shows up as lower average throughput." The first symptom is usually tail latency at moderate load.
- "Pinning to separate cores removes interference." Cores still share the last-level cache and memory controllers.
- "One antagonist experiment generalizes." Sensitivity depends on the resource, the load level and the specific pairing; sweep both.
How to approach it
Revisit your own co-location experiments with this vocabulary: which resource did each antagonist stress, where was it placed, and which percentile moved first? In research interviews, expect to design an experiment that separates mechanisms and to say which isolation control you would add and what it cannot protect.
Suggested order
- 1Read Leverich and Kozyrakis on memcached co-location and list the mechanisms they identify and the mitigations they test.
- 2Read Heracles and draw its controller: inputs, actuators and decision rules.
- 3Read Borg sections 5.2 (the CPI-based interference analysis) and 6.2 (performance isolation) with the Borg paper guide to see interference handled at cluster scale.
- 4Read the cgroup v2 descriptions of the cpu, cpuset, memory and io controllers, then the resctrl page for cache and memory-bandwidth allocation, and list what each can and cannot limit.
- 5Read the Kubernetes CPU management policies page and Firecracker sections 3.3 and 3.4 (rate limiters, security), and relate both to the mechanisms above.
- 6Plan or rerun an interference experiment with the revisit-coursework project.
Paper guides: Firecracker: Lightweight Virtualization for Serverless Applications, Large-scale cluster management at Google with Borg
Step 2: Check off what you can do
Tap each one you can genuinely do or explain. Each earns 10 XP.
Step 3: Go deeper
Reconciling High Server Utilization and Sub-millisecond Quality-of-ServiceStart here
Stanford University (author PDF)Mechanisms behind memcached tail-latency violations under co-location and mitigations, closest to typical coursework setups.
Open(opens in a new tab)Link responded, 5 Oct 2026Heracles: Improving Resource Efficiency at ScaleStart here
Google ResearchA feedback controller that coordinates several isolation mechanisms to co-locate batch work safely.
Open(opens in a new tab)Link responded, 5 Oct 2026Linux kernel documentation: User Interface for Resource Control (resctrl)
The Linux Kernel documentationCache and memory-bandwidth allocation (the resources cgroups do not partition), with a link to the cgroup v2 controller documentation.
Open(opens in a new tab)Link responded, 5 Oct 2026Firecracker: Lightweight Virtualization for Serverless Applications
USENIXSection: Sections 3.3–3.4: rate limiters and security
How a microVM design adds I/O rate limiting and relies on host-level side-channel mitigations, showing what a VM boundary does and does not isolate.
Open(opens in a new tab)Link responded, 5 Oct 2026Kubernetes: Pod Quality of Service classes, CPU management and bin packing
Kubernetes projectSection: Control CPU Management Policies on the Node
How Kubernetes grants exclusive cores and how QoS classes relate to isolation.
Open(opens in a new tab)Link responded, 5 Oct 2026
Step 4: Practice
Design an interference matrix: one latency-critical service (memcached is a good choice if you used it before) and three to five antagonists that each stress one resource. For each antagonist, measure the latency-versus-load curve with an open-loop generator at two placements (sibling hyperthread and separate core), with repetitions, and record cache-miss and bandwidth counters if available. Then apply one isolation control (pinning, a CPU cap or cache allocation) and report which curves move. Do not reuse old numbers you cannot trace to a log.
- Re-run and document one of your cloud coursework experimentsOpen(opens in a new tab)Not attemptedSelf-directed (your coursework setup)
Record attempts on each problem’s page (+15 XP, +10 more when solved on your own).
Step 5: Test yourself
Answer each one out loud or on paper before you finish the lesson.
- Question 1What is the difference between sensitivity and pressure?
- Question 2Why does a CPU quota not protect against a memory-bandwidth antagonist?
- Question 3Which resources do sibling hyperthreads share?
- Question 4What does a VM boundary protect, and what does it not?
- Question 5How would you tell scheduling delay apart from cache contention in an experiment?
You’re done when you can
- List the shared resources through which co-located workloads interfere and the isolation control for each, including what the control does not protect.
- Explain with queueing reasoning why interference shows up first in tail latency.
- Design an interference experiment with antagonists, placements, a load sweep, repetitions and counters.
- Describe how Heracles decides how much best-effort work to allow.
Finish the lesson
Unlocks next: Trace-driven evaluation and revisiting your cloud coursework


