A Hidden Cost of Virtualization When Scaling Multicore Applications
summary
Measured on PARSEC and SPLASH-2x workloads, scaling a VM to many virtual cores can slow some apps by up to 583% slowdown compared to bare metal because the VMM interrupts to handle IPIs and reschedule virtual cores whenever threads block and unblock. Microbenchmarks show wakeup jumps from ~8µs to ~37µs when cores are suspended. Two practical mitigations cut the loss: idleness consolidation (pack threads onto fewer vCPUs) and IPI-free wakeup (avoid VMM-injected IPIs), which together substantially reduce the slowdowns.
AI-written summary · about
chapters (9)
- 0:00Intro
- 0:28More Virtual Cores per VM is the Trend Amazon EC2 offers instances with 32 virtual cores.
- 2:00The Cost of Virtualization for Multicore Applications
- 4:05Extra Costs Must be paid for Blocking Synchronization in VM When threads are blocked at synchronization points - virtual cores become idle - Idle virtual cores are suspended by VMM
- 12:26Correlation between Application Slowdowns and Virtual Core Status Switches
- 16:17Basic Idea - Idleness Consolidation
- 20:35Slowdowns of the Benchmarks (with and without Mechanisms in Gleaner)
- 21:53Conclusion An understudied problem for running multicore applications in the cloud - The problem is caused block-synchronization in VMs. - A lot of work on VM overhead focuses 10 operations
- 24:59Costs of Rescheduling a Virtual Core and Handling IPI
related talks
09mKVM Latency Performance Tuning
41mLinux Systems Performance
19mDo nothing fast: How to scale idle cpus?
31mEnhancing Scalability of the Vmalloc Mechanism in the Linux Kernel
52mEffectively Measure and Reduce Kernel Latencies for Real-time Constraints
03h 01mHands-on Introduction to Virtualization
44mRestartable Sequences: Scheduler-Aware Scaling of Memory Use on Many-Core Systems
26mLessons Learned: Optimizing KVM Performance for EHR Systems