interviewpath
  • 0day streak
  • 10total XP
  • Level 1
0/5

Unit 13 · Cloud research · Lesson 2 of 5

Interference, noisy neighbors and performance isolation

Co-locating workloads raises utilization but lets them interfere through shared caches, memory bandwidth, CPU scheduling, network and storage, which shows up first as tail-latency violations. Knowing the mechanisms, the isolation tools from cgroups to microVMs, and how to measure interference credibly is central to cloud systems research.
About 4 hFocus mode

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

  1. 1Read Leverich and Kozyrakis on memcached co-location and list the mechanisms they identify and the mitigations they test.
  2. 2Read Heracles and draw its controller: inputs, actuators and decision rules.
  3. 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.
  4. 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.
  5. 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.
  6. 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 2026
  • Heracles: Improving Resource Efficiency at ScaleStart here

    Google Research

    A feedback controller that coordinates several isolation mechanisms to co-locate batch work safely.

    Open(opens in a new tab)Link responded, 5 Oct 2026
  • Linux kernel documentation: User Interface for Resource Control (resctrl)

    The Linux Kernel documentation

    Cache 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 2026
  • Firecracker: Lightweight Virtualization for Serverless Applications

    USENIX

    Section: 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 2026
  • Kubernetes: Pod Quality of Service classes, CPU management and bin packing

    Kubernetes project

    Section: 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.

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.

  1. Question 1What is the difference between sensitivity and pressure?
  2. Question 2Why does a CPU quota not protect against a memory-bandwidth antagonist?
  3. Question 3Which resources do sibling hyperthreads share?
  4. Question 4What does a VM boundary protect, and what does it not?
  5. 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

How confident do you feel?

Lesson complete!

+50 XP

Reviews will come up on the Practice tab so it sticks.

Unlocks next: Trace-driven evaluation and revisiting your cloud coursework

Your notes and study time

Log study time