Read alongside
Reconciling High Server Utilization and Sub-millisecond Quality-of-Service
Mechanisms behind memcached tail-latency violations under co-location and mitigations, closest to typical coursework setups.
Objectives
- Identify the shared hardware and software resources through which co-located workloads interfere and the symptom each produces.
- Explain with queueing reasoning why interference appears first in the tail latency of latency-critical services.
- Map isolation mechanisms (cgroup CPU and memory controls, cpusets and pinning, cache and memory-bandwidth allocation, I/O and network limits, VMs and microVMs) to what they protect and what they do not.
- Design an interference experiment with a latency-critical service, controlled antagonists, a load sweep, repetitions and percentile reporting.
- Describe how interference-aware controllers such as Heracles decide how much co-located work to allow.
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.
Self-check before you finish
- What is the difference between sensitivity and pressure?
- Why does a CPU quota not protect against a memory-bandwidth antagonist?
- Which resources do sibling hyperthreads share?
- What does a VM boundary protect, and what does it not?
- How would you tell scheduling delay apart from cache contention in an experiment?