KVM/ARM at Scale: Improvements to the MMU in the Face of Hardware Growing Pains
summary
Google Cloud runs a 48 vCPU VM with 192 GB RAM and two‑MiB huge pages to exercise dirty‑tracking; enabling dirty logging initially causes a 99% slowdown and a ~30s brownout. Kernel changes move the MMU from a spinlock to a read/write lock and add RCU protection for table ops, cutting the cliff to ~3–6s. The team implements a manual dirty log ioctl to rate‑limit eager page splits and avoid massive TLB broadcasts. Remaining pain comes from ARM’s break‑before‑make and TLB invalidation costs; TLBI‑range and level‑2 break‑before‑make hardware features look promising.
AI-written summary · about
chapters (9)
- 0:00Start
- 0:22Introduction
- 1:15Dirty Tracking on Arm
- 2:04Test Workload
- 2:51"Live" Migration
- 8:37Side effects of break-before-make
- 10:32Mitigating in software
- 14:20Acknowledgements
- 15:08Questions?
related talks
39mOptimizing CephFS with Combining MDS QoS Scheduling and Static-Dynamic Subtree Partitioning
32mOptimizing Resource Usage in Kubernetes
27mInsights on the Re-Architecting to a Single Codebase, Running on Different Hardware...
11mBuilding a Test for Diverse Fleet of Platforms, How Hard That Could Be?
15mvBOIDs: Taming Chaos via Coarse-Grained Scheduling Abstraction for Containers
01h 00mTrading at light speed: designing low latency systems in C++
30m8 Tips for Marathon Performance
41mBuilding the Future Trends in Modern Application Architecture