CPUfreq/sched and VM guest workload problems
summary
Runs RTF synthetic benchmarks comparing host vs VM on little/big cores and finds wrong vCPU capacity and VM frequency assumptions cause premature migrations and slow ramping — host moves in ~41 ms while VM hits its internal cap in ~35 ms and misroutes load. Real case: Android in container gets 27 FPS vs 10 FPS in VM. Proposal pins vCPUs to little/big, sets correct capacities and propagates real frequencies/util or clamps via a virtio CPUfreq driver, noting coordination breaks with multiple guests.
AI-written summary · about
chapters (11)
- 0:00Introduction to VM workload issues
- 1:45Synthetic benchmarks on host vs VM
- 6:03Real use case with Android in Chrome
- 7:07Current proposal for vCPU pinning
- 9:13Proposal for vCPU frequency driver
- 10:16Discussion on power management roles
- 15:32Feasibility of the proposal
- 17:18Utilization transfer between host and VM
- 20:08User space vs kernel space solutions
- 22:37Limited scope and next steps
- 26:12Summary and Q&A
related talks
45mDynamic vCPU priority boosting in KVM for latency sensitive workloads
39mEvaluation of PREEMPT_RT in Virtualized Environments
11mAdvanced Parallel Memory Virtualization
31mDebugging Tools and Techniques for Virtualized/Containerized Automotive Systems
38mPanel Discussion: KVM-based Virtualization Contributor Q&A
27mLive Migration With Hardware Acceleration
29mA Hidden Cost of Virtualization When Scaling Multicore Applications
17mAll Bark and no Bite: vCPU Stall Detection for KVM Guests