resourcemanagementforvirtualizedsystems

resourcemanagementforvirtualizedsystems内容摘要：

ce and workingset • Best data to guide decisions private to guest OS • Guest and metalevel policies may clash 25 Memory Virtualization  Extra level of indirection • Virtual  “Physical” Guest maps VPN to PPN using primary page tables • “Physical”  Machine VMM maps PPN to MPN  Shadow page table • Traditional VMM approach • Composite of two mappings • For ordinary memory references, hardware maps VPN to MPN  Nested page table hardware • Recent AMD RVI, Intel EPT • VMM manages PPNtoMPN table • No need for software shadows VPN PPN MPN hardware TLB shadow page table guest VMM 26 Reclaiming Memory  Required for memory overmitment • Increase consolidation ratio, incredibly valuable • Not supported by most hypervisors • Many VMware innovations [Waldspurger OSDI ’02]  Traditional: add transparent swap layer • Requires metalevel page replacement decisions • Best data to guide decisions known only by guest • Guest and metalevel policies may clash • Example: “double paging” anomaly  Alternative: implicit cooperation • Coax guest into doing page replacement • Avoid metalevel policy decisions 27 Ballooning Guest OS balloon Guest OS balloon Guest OS inflate balloon (+ pressure) deflate balloon (– pressure) may page out to virtual disk may page in from virtual disk guest OS manages memory implicit cooperation 28 Page Sharing  Motivation • Multiple VMs running same OS, apps • Deduplicate redundant copies of code, data, zeros  Transparent page sharing • Map multiple PPNs to single MPN copyonwrite • Pioneered by Disco [Bugnion et al. SOSP ’97], but required guest OS hooks  VMware contentbased sharing • Generalpurpose, no guest OS changes • Background activity saves memory over time 29 Page Sharing: Scan Candidate PPN VM 1 VM 2 VM 3 011010 110101 010111 101100 Machine Memory …06af 3 43f8 123b Hash: VM: PPN: MPN: hint frame hash table hash page contents …2bd806af 30 Page Sharing: Successful Match VM 1 VM 2 VM 3 Machine Memory …06af 2 123b Hash: Refs: MPN: shared frame hash table 31 Memory Reclamation: Future Directions  Memory pression • Old idea: pression cache [Douglis USENIX ’93], Connectix RAMDoubler (MacOS mid90s) • Recent: Difference Engine [Gupta et al. OSDI ’08], future VMware ESX release  Subpage deduplication  Emerging memory technologies • Swapping to SSD devices • Leveraging phasechange memory 32 Memory Allocation Policy  Traditional approach • Optimize aggregate systemwide metric • Problem: no QoS guarantees, VM importance varies  Pure sharebased approach • Revoke from VM with min sharesperpage ratio • Problem: ignores usage, unproductive hoarding  Desired behavior • VM gets full share when actively using memory • VM may lose pages when workingset shrinks 33 Reclaiming Idle Memory  Tax on idle memory • Charge more for idle page than active page • Idleadjusted sharesperpage ratio  Tax rate • Explicit administrative parameter • 0%  “plutocracy” … 100%  “socialism”  High default rate • Reclaim most idle memory • Some buffer against rapid workingset increases 34 Confidential Idle Memory Tax: 0%  Experiment • 2 VMs, 256 MB, same shares • VM1: Windows boot+idle • VM2: Linux boot+dbench • Solid: usage, Dotted: active  Change tax rate  Before: no tax • VM1 idle, VM2 active • Get same allocation 0501001502002503000 10 20 30 40 50 60Time (min)‏ Memory (MB)‏ 35 Idle Memory Tax: 75%  Experiment • 2 VMs, 256 MB, same shares • VM1: Windows boot+idle • VM2: Linux boot+dbench • Solid: usage, Dotted: activ。