A-DRM: Architecture-aware Distributed Resource Management of - - PowerPoint PPT Presentation

▶
a drm architecture aware distributed resource management
SMART_READER_LITE
LIVE PREVIEW

A-DRM: Architecture-aware Distributed Resource Management of - - PowerPoint PPT Presentation

Oct 09, 2022 132 likes •707 views

A-DRM: Architecture-aware Distributed Resource Management of Virtualized Clusters Hui Wang * , Canturk Isci , Lavanya Subramanian * , Jongmoo Choi #* , Depei Qian , Onur Mutlu * Beihang

slide-1
SLIDE 1

A-­‑DRM: ¡Architecture-­‑aware ¡ Distributed ¡Resource ¡Management ¡

  • f ¡Virtualized ¡Clusters

Hui ¡Wang†*, ¡Canturk Isci‡, ¡Lavanya Subramanian*, Jongmoo Choi#*, ¡Depei Qian†, ¡Onur Mutlu*

†Beihang University, ¡‡IBM ¡T. ¡J. ¡Watson ¡Research ¡Center,

*Carnegie ¡Mellon ¡University, ¡#Dankook University

slide-2
SLIDE 2

Executive ¡Summary

  • Virtualized ¡Clusters ¡dynamically ¡schedule ¡a ¡set ¡of ¡Virtual ¡Machines ¡(VM) ¡

across ¡many ¡physical ¡hosts ¡(called ¡DRM, ¡Distributed ¡Resource ¡ Management)

  • Observation: ¡State-­‑of-­‑the-­‑art ¡DRM ¡techniques ¡do ¡not ¡take ¡into ¡account ¡

microarchitecture-­‑level ¡resource ¡(cache ¡and ¡memory ¡bandwidth) ¡ interference ¡between ¡VMs

  • Problem: ¡This ¡lack ¡of ¡visibility ¡into ¡microarchitecture-­‑level ¡resources ¡

significantly ¡impacts ¡the ¡entire ¡virtualized ¡cluster’s ¡performance

  • Our ¡Goal: ¡Maximize ¡virtualized ¡cluster ¡performance ¡by ¡making ¡DRM ¡

microarchitecture ¡aware

  • Mechanism: ¡Architecture-­‑aware ¡Distributed ¡Resource ¡Management ¡(A-­‑

DRM):

1) ¡Dynamically ¡monitors ¡the ¡microarchitecture-­‑level ¡shared ¡resource ¡usage 2) ¡Balances ¡the ¡microarchitecture-­‑level ¡interference ¡across ¡the ¡cluster ¡(while ¡ accounting ¡for ¡other ¡resources ¡as ¡well)

  • Key ¡Results: ¡9.67% ¡higher ¡performance ¡and ¡17% ¡higher ¡memory ¡

bandwidth ¡utilization ¡than ¡conventional ¡DRM

2

slide-3
SLIDE 3

Virtualized ¡Cluster

3

Core0 Core1 Host LLC DRAM VM App VM App Core0 Core1 Host LLC DRAM VM App VM App

How ¡to ¡dynamically ¡ schedule ¡VMs ¡onto ¡ hosts?

Distributed ¡Resource ¡Management ¡ (DRM) ¡policies

slide-4
SLIDE 4

Conventional ¡DRM ¡Policies

4

Core0 Core1 Host LLC DRAM App App Core0 Core1 Host LLC DRAM VM App VM App VM App

Memory ¡Capacity CPU

Based ¡on ¡operating-­‑system-­‑level ¡metrics e.g., ¡CPU ¡utilization, ¡memory ¡capacity ¡ demand

slide-5
SLIDE 5

Microarchitecture-­‑level ¡Interference

5

VM App Core0 Core1 Host LLC DRAM VM App

  • VMs ¡within ¡a ¡host ¡compete ¡for:

– Shared ¡cache ¡capacity – Shared ¡memory ¡bandwidth

Can ¡operating-­‑system-­‑level ¡metrics ¡capture ¡the ¡ microarchitecture-­‑level ¡resource ¡interference?

slide-6
SLIDE 6

Microarchitecture ¡Unawareness

6

Core0 Core1 Host LLC DRAM VM App VM App Core0 Core1 Host LLC DRAM VM App VM App

VM

Operating-­‑system-­‑level ¡metrics CPU ¡Utilization Memory ¡Capacity

92% 369 MB 93% 348 MB App App STREAM gromacs

Microarchitecture-­‑level ¡metrics LLC ¡Hit ¡Ratio Memory ¡Bandwidth

2% 2267 ¡MB/s 98% 1 MB/s VM App

Memory ¡Capacity CPU

slide-7
SLIDE 7

Impact ¡on ¡Performance

7 0.0 0.2 0.4 0.6

IPC ¡ (Harmonic ¡ Mean) Conventional ¡DRM with ¡Microarchitecture ¡Awareness

Core0 Core1 Host LLC DRAM VM App VM App Core0 Core1 Host LLC DRAM VM App VM App App STREAM gromacs VM App

Memory ¡Capacity CPU

SWAP

slide-8
SLIDE 8

Impact ¡on ¡Performance

8 0.0 0.2 0.4 0.6

IPC ¡ (Harmonic ¡ Mean) Conventional ¡DRM with ¡Microarchitecture ¡Awareness

49% Core0 Core1 Host LLC DRAM VM App VM App Core0 Core1 Host LLC DRAM VM App VM App App STREAM gromacs VM App

Memory ¡Capacity CPU

We ¡need ¡microarchitecture-­‑ level ¡interference ¡awareness ¡in ¡ DRM!

slide-9
SLIDE 9

Outline

  • Motivation
  • A-­‑DRM
  • Methodology
  • Evaluation
  • Conclusion

9

slide-10
SLIDE 10

A-­‑DRM: ¡Architecture-­‑aware ¡DRM

  • Goal: ¡Take ¡into ¡account ¡microarchitecture-­‑level ¡

shared ¡resource ¡interference

– Shared ¡cache ¡capacity – Shared ¡memory ¡bandwidth

  • Key ¡Idea: ¡

– Monitor ¡and ¡detect ¡microarchitecture-­‑level ¡shared ¡ resource ¡interference – Balance ¡microarchitecture-­‑level ¡resource ¡usage ¡across ¡ cluster

10

slide-11
SLIDE 11

Conventional ¡DRM

11

OS+Hypervisor VM App VM App DRM: ¡Global ¡Resource ¡Manager Profiling ¡Engine Distributed ¡Resource ¡ Management ¡(Policy) Migration ¡Engine Hosts Controller

CPU/Memory ¡Capacity

Profiler

slide-12
SLIDE 12

A-­‑DRM: ¡Architecture-­‑aware ¡DRM

12

OS+Hypervisor VM App VM App A-­‑DRM: ¡Global ¡Architecture ¡– aware ¡Resource ¡Manager Profiling ¡Engine Architecture-­‑aware Interference ¡Detector Architecture-­‑aware ¡ Distributed ¡Resource ¡ Management ¡(Policy) Migration ¡Engine Hosts Controller

CPU/Memory ¡ Capacity

Profiler

Architectural ¡ Resource

  • Architectural ¡

Resources

slide-13
SLIDE 13

Architectural ¡Resource ¡Profiler

  • Leverages ¡the ¡Hardware ¡Performance ¡

Monitoring ¡Units ¡(PMUs):

– Last ¡level ¡cache ¡(LLC) ¡ – Memory ¡bandwidth ¡(MBW)

  • Reports ¡to ¡Controller ¡periodically

13

slide-14
SLIDE 14

A-­‑DRM: ¡Architecture-­‑aware ¡DRM

14

OS+Hypervisor VM App VM App A-­‑DRM: ¡Global ¡Architecture ¡– aware ¡Resource ¡Manager Profiling ¡Engine Architecture-­‑aware Interference ¡Detector Architecture-­‑aware ¡ Distributed ¡Resource ¡ Management ¡(Policy) Migration ¡Engine Hosts Controller

CPU/Memory

Profiler

Architectural ¡ Resource

  • Architectural ¡

Resources

slide-15
SLIDE 15

Architecture-­‑aware ¡Interference ¡Detector

15

  • Goal: ¡Detect ¡shared ¡cache ¡capacity ¡and ¡memory ¡

bandwidth ¡interference

  • Memory ¡bandwidth ¡utilization ¡(MBWutil) ¡captures ¡both:

– Shared ¡cache ¡capacity ¡interference – Shared ¡memory ¡bandwidth ¡interference

Core0 Core1 Host LLC DRAM VM App VM App

Key ¡observation: ¡If ¡MBWutil is ¡too ¡high, ¡the ¡host ¡is ¡ experiencing ¡interference

slide-16
SLIDE 16

A-­‑DRM: ¡Architecture-­‑aware ¡DRM

16

OS+Hypervisor VM App VM App A-­‑DRM: ¡Global ¡Architecture ¡– aware ¡Resource ¡Manager Profiling ¡Engine Architecture-­‑aware Interference ¡Detector Architecture-­‑aware ¡ Distributed ¡Resource ¡ Management ¡(Policy) Migration ¡Engine Hosts Controller

CPU/Memory

Profiler

Architectural ¡ Resource

  • Architectural ¡

Resources

slide-17
SLIDE 17

A-­‑DRM ¡Policy

  • Two-­‑phase ¡algorithm
  • Phase ¡One: ¡

– Goal: ¡Mitigate ¡microarchitecture-­‑level ¡resource ¡ interference – Key ¡Idea: ¡ ¡Suggest ¡migrations ¡to ¡balance ¡memory ¡ bandwidth ¡utilization across ¡cluster ¡using ¡a ¡new ¡cost-­‑ benefit ¡analysis

  • Phase ¡Two:

– Goal: ¡Finalize ¡migration ¡decisions by ¡also ¡taking ¡into ¡ account ¡OS-­‑level ¡metrics ¡(similar ¡to ¡conventional ¡DRM)

17

slide-18
SLIDE 18

A-­‑DRM ¡Policy: ¡Phase ¡One

  • Goal: ¡Mitigate ¡microarchitecture-­‑level ¡shared ¡resource ¡

interference

– Employ ¡a ¡new ¡cost-­‑benefit ¡analysis to ¡filter ¡out ¡migrations ¡that ¡cannot ¡ provide ¡enough ¡benefit – Only ¡migrate ¡the ¡least ¡number ¡of ¡VMs ¡required ¡to ¡bring ¡the ¡MBWutil below ¡a ¡threshold ¡(MBWThreshold)

18

App High ¡MBW Low ¡MBW Core0 Core1 LLC DRAM VM App Core0 Core1 LLC DRAM VM App VM App VM App Source Destination

slide-19
SLIDE 19

A-­‑DRM ¡Policy: ¡Phase ¡Two

  • Goals: ¡

– Finalize ¡migration ¡decisions ¡by ¡also ¡taking ¡into ¡account ¡OS-­‑level ¡ metrics – Avoid ¡new ¡microarchitecture-­‑level ¡resource ¡hotspots

19

Core0 Core1 Source LLC DRAM VM App Core0 Core1 Destination LLC DRAM VM App VM App App High ¡MBW Low ¡MBW VM App

slide-20
SLIDE 20

A-­‑DRM ¡Policy

  • Two-­‑phase ¡algorithm
  • Phase ¡One: ¡

– Goal: ¡Mitigate ¡microarchitecture-­‑level ¡resource ¡ interference – Key ¡Idea: ¡ ¡Suggest ¡migrations ¡to ¡balance ¡memory ¡ bandwidth ¡utilization across ¡cluster ¡using ¡a ¡new ¡cost-­‑ benefit ¡analysis

  • Phase ¡Two:

– Goal: ¡Finalize ¡migration ¡decisions by ¡also ¡taking ¡into ¡ account ¡OS-­‑level ¡metrics ¡(similar ¡to ¡conventional ¡DRM)

20

slide-21
SLIDE 21

The ¡Goal ¡of ¡Cost-­‑Benefit ¡Analysis

  • For ¡every ¡VM ¡at ¡a ¡contended ¡host, ¡we ¡need ¡to ¡

determine:

– If ¡we ¡should ¡migrate ¡it – Where ¡we ¡should ¡migrate ¡it

  • For ¡each ¡VM ¡at ¡a ¡contended ¡source, ¡we ¡consider ¡

migrating ¡it ¡to ¡every ¡uncontended ¡destination

  • We ¡develop ¡a ¡new ¡linear ¡model ¡to ¡estimate ¡the ¡

performance ¡degradation/improvement ¡in ¡terms ¡of ¡ time

21

slide-22
SLIDE 22

Cost-­‑Benefit ¡Analysis

  • Costs of ¡migrating ¡a ¡VM ¡include: ¡

1) ¡VM ¡migration ¡cost ¡(𝐷𝑝𝑡𝑢%&'()*&+,), ¡ 2) ¡Performance ¡degradation ¡at ¡the ¡destination ¡host ¡due ¡to ¡increased ¡ interference ¡(𝐷𝑝𝑡𝑢-.*)

  • Benefits ¡of ¡migrating ¡a ¡VM include:

1) ¡Performance ¡improvement ¡of ¡the ¡migrated ¡VM ¡(𝐶𝑓𝑜𝑓𝑔𝑗𝑢4%), 2) ¡Performance ¡improvement ¡of ¡the ¡other ¡VMs ¡on ¡the ¡source ¡host ¡due ¡to ¡ reduced ¡interference ¡(𝐶𝑓𝑜𝑓𝑔𝑗𝑢.(5)

22

Core0 Core1 src LLC DRAM VM App Core0 Core1 dst LLC DRAM VM App VM App VM App VM App

Phase ¡One ¡of ¡A-­‑DRM ¡suggests ¡migrating ¡a ¡VM ¡if

𝐶𝑓𝑜𝑓𝑔𝑗𝑢4% + 𝐶𝑓𝑜𝑓𝑔𝑗𝑢.(5 > 𝐷𝑝𝑡𝑢%&'()*&+, + 𝐷𝑝𝑡𝑢-.*

slide-23
SLIDE 23

Cost-­‑Benefit ¡Analysis

  • Costs of ¡migrating ¡a ¡VM ¡include: ¡

1) ¡VM ¡migration ¡cost ¡(𝐷𝑝𝑡𝑢%&'()*&+,), ¡ 2) ¡Performance ¡degradation ¡at ¡the ¡destination ¡host ¡due ¡to ¡increased ¡ interference ¡(𝐷𝑝𝑡𝑢-.*)

  • Benefits ¡of ¡migrating ¡a ¡VM include:

1) ¡Performance ¡improvement ¡of ¡the ¡migrated ¡VM ¡(𝐶𝑓𝑜𝑓𝑔𝑗𝑢4%), 2) ¡Performance ¡improvement ¡of ¡the ¡other ¡VMs ¡on ¡the ¡source ¡host ¡due ¡to ¡ reduced ¡interference ¡(𝐶𝑓𝑜𝑓𝑔𝑗𝑢.(5)

23

Phase ¡One ¡of ¡A-­‑DRM ¡suggests ¡migrating ¡a ¡VM ¡if

𝐶𝑓𝑜𝑓𝑔𝑗𝑢4% + 𝐶𝑓𝑜𝑓𝑔𝑗𝑢.(5 > 𝐷𝑝𝑡𝑢%&'()*&+, + 𝐷𝑝𝑡𝑢-.*

slide-24
SLIDE 24

𝑫𝒑𝒕𝒖𝒏𝒋𝒉𝒔𝒃𝒖𝒋𝒑𝒐: ¡VM ¡migration

  • VM ¡migration ¡approach ¡used ¡in ¡A-­‑DRM:

– ‘Pre-­‑copy-­‑based’ ¡live ¡migration ¡+ ¡timeout ¡support

  • High ¡cost ¡since ¡all ¡of ¡the ¡VM’s ¡pages ¡need ¡to ¡be ¡

iteratively:

– scanned, ¡tracked – transferred

  • The ¡migration ¡time ¡can ¡be ¡estimated ¡similar ¡to ¡

conventional ¡DRM ¡policies

24

slide-25
SLIDE 25

Cost-­‑Benefit ¡Analysis

  • Costs of ¡migrating ¡a ¡VM ¡include: ¡

1) ¡VM ¡migration ¡cost ¡(𝐷𝑝𝑡𝑢%&'()*&+,), ¡ 2) ¡Performance ¡degradation ¡at ¡the ¡destination ¡host ¡due ¡to ¡increased ¡ interference ¡(𝐷𝑝𝑡𝑢-.*)

  • Benefits ¡of ¡migrating ¡a ¡VM include:

1) ¡Performance ¡improvement ¡of ¡the ¡migrated ¡VM ¡(𝐶𝑓𝑜𝑓𝑔𝑗𝑢4%), 2) ¡Performance ¡improvement ¡of ¡the ¡other ¡VMs ¡on ¡the ¡source ¡host ¡due ¡to ¡ reduced ¡interference ¡(𝐶𝑓𝑜𝑓𝑔𝑗𝑢.(5)

25

Phase ¡One ¡of ¡A-­‑DRM ¡suggests ¡migrating ¡a ¡VM ¡if

𝐶𝑓𝑜𝑓𝑔𝑗𝑢4% + 𝐶𝑓𝑜𝑓𝑔𝑗𝑢.(5 > 𝐷𝑝𝑡𝑢%&'()*&+, + 𝐷𝑝𝑡𝑢-.*

slide-26
SLIDE 26

𝑫𝒑𝒕𝒖𝒆𝒕𝒖: ¡Performance ¡Degradation ¡at ¡dst

  • The ¡migrated ¡vm competes ¡for:

– Shared ¡cache ¡capacity – Shared ¡memory ¡bandwidth

  • Performance ¡at ¡dst degrades ¡due ¡

to:

– Increase ¡in ¡memory ¡bandwidth ¡ consumption – Increase ¡in ¡the ¡memory ¡stall time ¡ experienced ¡by ¡VMs

26

VM App Core0 Core1

dst

LLC DRAM VM App vm App

slide-27
SLIDE 27

Cost-­‑Benefit ¡Analysis

  • Costs of ¡migrating ¡a ¡VM ¡include: ¡

1) ¡VM ¡migration ¡cost ¡(𝐷𝑝𝑡𝑢%&'()*&+,), ¡ 2) ¡Performance ¡degradation ¡at ¡the ¡destination ¡host ¡due ¡to ¡increased ¡ interference ¡(𝐷𝑝𝑡𝑢-.*)

  • Benefits ¡of ¡migrating ¡a ¡VM include:

1) ¡Performance ¡improvement ¡of ¡the ¡migrated ¡VM ¡(𝐶𝑓𝑜𝑓𝑔𝑗𝑢4%), 2) ¡Performance ¡improvement ¡of ¡the ¡other ¡VMs ¡on ¡the ¡source ¡host ¡due ¡to ¡ reduced ¡interference ¡(𝐶𝑓𝑜𝑓𝑔𝑗𝑢.(5)

27

Phase ¡One ¡of ¡A-­‑DRM ¡suggests ¡migrating ¡a ¡VM ¡if

𝐶𝑓𝑜𝑓𝑔𝑗𝑢4% + 𝐶𝑓𝑜𝑓𝑔𝑗𝑢.(5 > 𝐷𝑝𝑡𝑢%&'()*&+, + 𝐷𝑝𝑡𝑢-.*

slide-28
SLIDE 28

𝑪𝒇𝒐𝒇𝒈𝒋𝒖𝒘𝒏: ¡Performance ¡improvement ¡of ¡vm

28

Core0 Core1

src

LLC DRAM VM App Core0 Core1

dst

LLC DRAM VM App VM App

  • The ¡performance ¡of ¡migrated ¡vm improves ¡

due ¡to:

– Lower ¡contention ¡for ¡memory ¡bandwidth – Lower ¡memory ¡stall time

vm App

slide-29
SLIDE 29

Cost-­‑Benefit ¡Analysis

  • Costs of ¡migrating ¡a ¡VM ¡include: ¡

1) ¡VM ¡migration ¡cost ¡(𝐷𝑝𝑡𝑢%&'()*&+,), ¡ 2) ¡Performance ¡degradation ¡at ¡the ¡destination ¡host ¡due ¡to ¡increased ¡ interference ¡(𝐷𝑝𝑡𝑢-.*)

  • Benefits ¡of ¡migrating ¡a ¡VM include:

1) ¡Performance ¡improvement ¡of ¡the ¡migrated ¡VM ¡(𝐶𝑓𝑜𝑓𝑔𝑗𝑢4%), 2) ¡Performance ¡improvement ¡of ¡the ¡other ¡VMs ¡on ¡the ¡source ¡host ¡due ¡to ¡ reduced ¡interference ¡(𝐶𝑓𝑜𝑓𝑔𝑗𝑢.(5)

29

Phase ¡One ¡of ¡A-­‑DRM ¡suggests ¡migrating ¡a ¡VM ¡if

𝐶𝑓𝑜𝑓𝑔𝑗𝑢4% + 𝐶𝑓𝑜𝑓𝑔𝑗𝑢.(5 > 𝐷𝑝𝑡𝑢%&'()*&+, + 𝐷𝑝𝑡𝑢-.*

slide-30
SLIDE 30

𝑪𝒇𝒐𝒇𝒈𝒋𝒖𝒕𝒔𝒅: ¡Performance ¡improvement ¡at ¡src

30

  • The ¡performance ¡at ¡src improves ¡

due ¡to:

– Reduced ¡memory ¡bandwidth ¡ consumption – Reduced ¡stall time ¡experienced ¡by ¡ VMs

Core0 Core1

src

LLC DRAM VM App VM App

slide-31
SLIDE 31

A-­‑DRM ¡Policy

  • Two-­‑phase ¡algorithm
  • Phase ¡One: ¡

– Goal: ¡Mitigate ¡microarchitecture-­‑level ¡resource ¡ interference – Key ¡Idea: ¡ ¡Suggest ¡migrations ¡to ¡balance ¡memory ¡ bandwidth ¡utilization across ¡cluster ¡using ¡a ¡new ¡cost-­‑ benefit ¡analysis

  • Phase ¡Two:

– Goal: ¡Finalize ¡migration ¡decisions by ¡also ¡taking ¡into ¡ account ¡OS-­‑level ¡metrics ¡(similar ¡to ¡conventional ¡DRM)

31

slide-32
SLIDE 32

Outline

  • Motivation
  • A-­‑DRM
  • Methodology
  • Evaluation
  • Conclusion

32

slide-33
SLIDE 33

Evaluation ¡Infrastructure

  • 2/4 ¡dual-­‑socket ¡Hosts

– Two ¡4-­‑core ¡Xeon ¡L5630 ¡Processors ¡(Westmere-­‑EP) ¡ with ¡hyperthreading disabled

  • L1/L2/shared ¡LLC: ¡32KB/256KB/12MB

– One ¡8GB ¡DDR3-­‑1066 ¡DIMM ¡per ¡socket

  • VM ¡Images ¡placed ¡in ¡shared ¡storage ¡(NAS)
  • OS ¡and ¡Hypervisor:

– Fedora ¡20 ¡with ¡Linux ¡Kernel ¡version ¡3.13.5-­‑202 – QEMU: ¡1.6.2 – Libvirt: ¡1.1.3.5

33

Core Socket ¡1 LLC DRAM Host QPI Core Core Core Core Socket ¡2 LLC DRAM Core Core Core

slide-34
SLIDE 34

DRM ¡Parameters

34

Parameter Value CPU overcommit ¡threshold ¡(𝐷𝑄𝑉𝑈ℎ𝑠𝑓𝑡ℎ𝑝𝑚𝑒) 90% Memory ¡overcommit ¡threshold ¡(𝑁𝐹𝑁𝑈ℎ𝑠𝑓𝑡ℎ𝑝𝑚𝑒) 95% Memory ¡bandwidth ¡threshold ¡(𝑁𝐶𝑋𝑈ℎ𝑠𝑓𝑡ℎ𝑝𝑚𝑒) 60% DRM ¡scheduling ¡interval ¡(𝑡𝑑ℎ𝑓𝑒𝑣𝑚𝑗𝑜𝑕 ¡𝑗𝑜𝑢𝑓𝑠𝑤𝑏𝑚) 300 seconds DRM ¡sliding ¡window ¡size 80 ¡samples Profiling ¡interval ¡(𝑞𝑠𝑝𝑔𝑗𝑚𝑗𝑜𝑕 ¡𝑗𝑜𝑢𝑓𝑠𝑤𝑏𝑚) 5 ¡seconds Live ¡migration ¡timeout ¡(𝑚𝑗𝑤𝑓 ¡𝑛𝑗𝑕𝑠𝑏𝑢𝑗𝑝𝑜 ¡𝑢𝑗𝑛𝑓𝑝𝑣𝑢) 30 ¡seconds

  • Baseline: ¡Conventional ¡DRM ¡[Isci et ¡al., ¡NOMS’ ¡10]
slide-35
SLIDE 35

Workloads

  • 55 ¡Workloads ¡chosen ¡from:

– PARSEC ¡(10) – SPEC ¡CPU ¡2006 ¡(28) – NAS ¡Parallel ¡Benchmark ¡(14) – STREAM ¡(1) – Microbenchmark (2)

  • Classified ¡based ¡on ¡memory ¡intensity:

– memory-­‑intensive ¡(memory ¡bandwidth ¡larger ¡than ¡ 1GB/s) – memory-­‑non-­‑intensive

35

slide-36
SLIDE 36

Outline

  • Motivation
  • A-­‑DRM
  • Methodology
  • Evaluation
  • 1. ¡Case ¡Study
  • 2. ¡Heterogeneous ¡Workloads
  • 3. ¡Per-­‑Host ¡vs. ¡Per-­‑Socket ¡Interference ¡Detection
  • Conclusion

36

slide-37
SLIDE 37
  • 1. ¡Case ¡Study
  • 14 ¡VMs ¡on ¡two 8-­‑core ¡hosts
  • Initially:

– Host ¡A: ¡7 ¡memory-­‑intensive ¡VMs ¡(STREAM) – Host ¡B: ¡7 ¡memory-­‑non-­‑intensive ¡VMs ¡(gromacs)

37

MBW ¡ Demand H L

Host ¡A Host ¡B

Memory ¡Bandwidth ¡Enough Memory ¡Bandwidth ¡Starved Host ¡State

slide-38
SLIDE 38

38 Host ¡A Host ¡B

50 100 300 CPU_ALL(A) CPU_ALL(B) 50 100 300 MEM_ALL(A) MEM_ALL(B) 50 100 300 MBW_ALL(A) MBW_ALL(B)

CPU ¡ Util [%] MBW Util [%]

Host ¡A Host ¡B

Mem ¡Capacity Util [%]

slide-39
SLIDE 39

39

50 100 300 600 CPU_ALL(A) CPU_ALL(B) 50 100 300 600 MEM_ALL(A) MEM_ALL(B) 50 100 300 600 MBW_ALL(A) MBW_ALL(B)

Host ¡A Host ¡B

CPU ¡ Util [%] MBW Util [%]

Host ¡A Host ¡B

Mem ¡Capacity Util [%]

slide-40
SLIDE 40

40

50 100 300 600 900 CPU_ALL(A) CPU_ALL(B) 50 100 300 600 900 MEM_ALL(A) MEM_ALL(B) 50 100 300 600 900 MBW_ALL(A) MBW_ALL(B)

Host ¡A Host ¡B

CPU ¡ Util [%] MBW Util [%]

Host ¡A Host ¡B

Mem ¡Capacity Util [%]

slide-41
SLIDE 41
  • By ¡migrating ¡VMs ¡using ¡online ¡measurement ¡of ¡

microarchitecture-­‑level ¡resource ¡usage, ¡A-­‑DRM:

– Mitigates ¡resource ¡interference – Achieves ¡better ¡memory ¡bandwidth ¡utilization

41

50 100 300 600 900 CPU_ALL(A) CPU_ALL(B) 50 100 300 600 900 MEM_ALL(A) MEM_ALL(B) 50 100 300 600 900 MBW_ALL(A) MBW_ALL(B)

Host ¡A Host ¡B

CPU ¡ Util [%] Mem ¡Capacity Util [%] MBW Util [%]

Host ¡A Host ¡B

slide-42
SLIDE 42

Outline

  • Motivation
  • A-­‑DRM
  • Methodology
  • Evaluation
  • 1. ¡Case ¡Study
  • 2. ¡Heterogeneous ¡Workloads
  • 3. ¡Per-­‑Host ¡vs. ¡Per-­‑Socket ¡Interference ¡Detection
  • Conclusion

42

slide-43
SLIDE 43
  • 2. ¡Heterogeneous ¡workloads

43

  • 28 ¡VMs ¡on ¡four 8-­‑core ¡hosts
  • Unbalanced ¡placement ¡according ¡to ¡intensity
  • Workloads ¡(denoted ¡as ¡iXnY-­‑Z):

– X VMs ¡running ¡memory-­‑intensive benchmarks – Y VMs ¡running ¡memory-­‑non-­‑intensive benchmarks – Z indicates ¡the ¡two ¡different ¡workloads ¡under ¡the ¡ same ¡intensity

slide-44
SLIDE 44

0% 5% 10% 15% 20% 25% 30%

i07n21… i07n21… i08n20… i08n20… i09n19… i09n19… i10n18… i10n18… i11n17… i11n17… i12n16… i12n16… i13n15… i13n15… i14n14… i14n14… i15n13… i15n13… i16n12… i16n12… i17n11… i17n11… i18n10… i18n10… i19n09… i19n09… i20n08… i20n08… i21n07… i21n07… average

IPC ¡Improvement ¡[%]

44

Performance ¡Benefits ¡of ¡A-­‑DRM

  • Compared ¡to ¡traditional ¡DRM ¡scheme:

– Performance ¡improves ¡by ¡up ¡to ¡26.6%, ¡with ¡an ¡average ¡of ¡ 9.7% – The ¡higher ¡the ¡imbalance ¡between ¡hosts, ¡the ¡greater ¡the ¡ performance ¡improvement

9.7%

slide-45
SLIDE 45

45

Number ¡of ¡Migrations

4 8 12 16

i07n21-­‑1 i07n21-­‑2 i08n20-­‑1 i08n20-­‑2 i09n19-­‑1 i09n19-­‑2 i10n18-­‑1 i10n18-­‑2 i11n17-­‑1 i11n17-­‑2 i12n16-­‑1 i12n16-­‑2 i13n15-­‑1 i13n15-­‑2 i14n14-­‑1 i14n14-­‑2 i15n13-­‑1 i15n13-­‑2 i16n12-­‑1 i16n12-­‑2 i17n11-­‑1 i17n11-­‑2 i18n10-­‑1 i18n10-­‑2 i19n09-­‑1 i19n09-­‑2 i20n08-­‑1 i20n08-­‑2 i21n07-­‑1 i21n07-­‑2 average

  • The ¡higher ¡the ¡imbalance ¡between ¡hosts, ¡the ¡

greater ¡the ¡number ¡of ¡migrations

6

slide-46
SLIDE 46

0.90 1.00 1.10 1.20 CPU MEM MBW Normalized ¡ Resource ¡Utilization Traditional ¡DRM A-­‑DRM

Cluster-­‑wide ¡Resource ¡Utilization

  • Average memory ¡bandwidth ¡utilization ¡improves ¡by ¡17%
  • Comparable ¡CPU ¡and ¡memory ¡capacity ¡utilization

46

slide-47
SLIDE 47

Outline

  • Motivation
  • A-­‑DRM
  • Methodology
  • Evaluation
  • 1. ¡Case ¡Study
  • 2. ¡Heterogeneous ¡Workloads
  • 3. ¡Per-­‑Host ¡vs. ¡Per-­‑Socket ¡Interference ¡Detection
  • Conclusion

47

slide-48
SLIDE 48

Per-­‑Host ¡vs. ¡Per-­‑Socket ¡Interference ¡Detection

48

Core ¡ Core Socket ¡1 LLC DRAM VM

App

VM

App

Host ¡A Core Core Socket ¡2 LLC DRAM VM

App

VM

App

QPI Core Core Socket ¡1 LLC DRAM VM

App

VM

App

Host ¡B Core Core Socket ¡2 LLC DRAM VM

App

VM

App

QPI

Per-­‑Host Per-­‑Socket

slide-49
SLIDE 49

0% 5% 10% 15% 20% 25%

i n 1 4 i 1 n 1 3 i 2 n 1 2 i 3 n 1 1 i 4 n 1 i 5 n 9 i 6 n 8 i 7 n 7 i 8 n 6 i 9 n 5 i 1 n 4 i 1 1 n 3 i 1 2 n 2 i 1 3 n 1 i 1 4 n a v e r a g e

Relative ¡IPC ¡Improvement Per-­‑Host ¡Detection Per-­‑Socket ¡Detection

Performance ¡Benefits ¡of ¡Per-­‑Host ¡vs. ¡Per-­‑Socket

49

  • Per-­‑Socket ¡Detection ¡achieves ¡better ¡IPC ¡improvement ¡

than ¡Per-­‑Host ¡Detection

slide-50
SLIDE 50

Outline

  • Motivation
  • A-­‑DRM
  • Methodology
  • Evaluation
  • Conclusion

50

slide-51
SLIDE 51

Conclusion

  • Virtualized ¡Clusters ¡dynamically ¡schedule ¡a ¡set ¡of ¡Virtual ¡Machines ¡(VM) ¡

across ¡many ¡physical ¡hosts ¡(called ¡DRM, ¡Distributed ¡Resource ¡ Management)

  • Observation: ¡State-­‑of-­‑the-­‑art ¡DRM ¡techniques ¡do ¡not ¡take ¡into ¡account ¡

microarchitecture-­‑level ¡resource ¡(cache ¡and ¡memory ¡bandwidth) ¡ interference ¡between ¡VMs

  • Problem: ¡This ¡lack ¡of ¡visibility ¡into ¡microarchitecture-­‑level ¡resources ¡

significantly ¡impacts ¡the ¡entire ¡virtualized ¡cluster’s ¡performance

  • Our ¡Goal: ¡Maximize ¡virtualized ¡cluster ¡performance ¡by ¡making ¡DRM ¡

microarchitecture ¡aware

  • Mechanism: ¡Architecture-­‑aware ¡Distributed ¡Resource ¡Management ¡(A-­‑

DRM):

1) ¡Dynamically ¡monitors ¡the ¡microarchitecture-­‑level ¡shared ¡resource ¡usage 2) ¡Balances ¡the ¡microarchitecture-­‑level ¡interference ¡across ¡the ¡cluster ¡(while ¡ accounting ¡for ¡other ¡resources ¡as ¡well)

  • Key ¡Results: ¡9.67% ¡higher ¡performance ¡and ¡17% ¡higher ¡memory ¡

bandwidth ¡utilization ¡than ¡conventional ¡DRM

51

slide-52
SLIDE 52

A-­‑DRM: ¡Architecture-­‑aware ¡ Distributed ¡Resource ¡Management

  • f ¡Virtualized ¡Clusters

Hui ¡Wang†*, ¡Canturk Isci‡, ¡Lavanya Subramanian*, Jongmoo Choi#*, ¡Depei Qian†, ¡Onur Mutlu*

†Beihang University, ¡‡IBM ¡T. ¡J. ¡Watson ¡Research ¡Center,

*Carnegie ¡Mellon ¡University, ¡#Dankook University

slide-53
SLIDE 53

Backup ¡Slides

Hui ¡Wang†*, ¡Canturk Isci‡, ¡Lavanya Subramanian*, Jongmoo Choi#*, ¡Depei Qian†, ¡Onur Mutlu*

†Beihang University, ¡‡IBM ¡T. ¡J. ¡Watson ¡Research ¡Center,

*Carnegie ¡Mellon ¡University, ¡#Dankook University

slide-54
SLIDE 54
  • A linear ¡model:

– the ¡stall cycles ¡is ¡proportional ¡to ¡the ¡Miss ¡Per ¡Kilo ¡ Cycles ¡(MPKC)

54

Performance ¡Modeling

𝑇𝑢𝑏𝑚𝑚 = 𝑂𝑣𝑛𝑀𝑀𝐷𝐼𝑗𝑢𝑡×𝑀𝑀𝐷𝑀𝑏𝑢𝑓𝑜𝑑𝑧 +𝑂𝑣𝑛𝐸𝑆𝐵𝑁𝐵𝑑𝑑𝑓𝑡𝑡𝑓𝑡×𝐵𝑤𝑕𝐸𝑆𝐵𝑁𝑀𝑏𝑢𝑓𝑜𝑑𝑧 𝑂𝑓𝑥𝑇𝑢𝑏𝑚𝑚& = 𝑇𝑢𝑏𝑚𝑚&× 𝑁𝑄𝐿𝐷-.* + 𝑁𝑄𝐿𝐷4% 𝑁𝑄𝐿𝐷-.* , ∀𝑗 ∈ 𝑒𝑡𝑢 𝐸𝑓𝑚𝑢𝑏𝑇𝑢𝑏𝑚𝑚& = 𝑇𝑢𝑏𝑚𝑚&×𝑁𝑄𝐿𝐷4% 𝑁𝑄𝐿𝐷-.*

slide-55
SLIDE 55

Execution ¡Time ¡vs. ¡IPC

55

0.00% 10.00% 20.00% i00n14 i01n13 i02n12 i03n11 i04n10 i05n09 i06n08 i07n07 i08n06 i09n05 i10n04 i11n03 i12n02 i13n01 i14n00 average

Execution ¡Time

0.00% 10.00% 20.00% 30.00% i00n14 i01n13 i02n12 i03n11 i04n10 i05n09 i06n08 i07n07 i08n06 i09n05 i10n04 i11n03 i12n02 i13n01 i14n00 average

IPC

slide-56
SLIDE 56

0.1 0.2 0.3 0.4 0.5 50% 60% 70% 80% IPC ¡(Harmonic ¡Mean)

Parameter ¡Sensitivity

56 4 8 12 16 50% 60% 70% 80% Number ¡of ¡Migration 0.1 0.2 0.3 0.4 0.5 5s 30s 60s IPC ¡(Harmonic ¡Mean) 0.1 0.2 0.3 0.4 0.5 20 40 60 80 IPC ¡(Harmonic ¡Mean)

slide-57
SLIDE 57

57 0% 10% 20% 30% 40% 50%

Reduction ¡in ¡ Maximum ¡ Slowdown ¡[%] ¡

0% 1% 2% 3% 4% 5% 6% 7% i07n21-­‑1 i07n21-­‑2 i08n20-­‑1 i08n20-­‑2 i09n19-­‑1 i09n19-­‑2 i10n18-­‑1 i10n18-­‑2 i11n17-­‑1 i11n17-­‑2 i12n16-­‑1 i12n16-­‑2 i13n15-­‑1 i13n15-­‑2 i14n14-­‑1 i14n14-­‑2 i15n13-­‑1 i15n13-­‑2 i16n12-­‑1 i16n12-­‑2 i17n11-­‑1 i17n11-­‑2 i18n10-­‑1 i18n10-­‑2 i19n09-­‑1 i19n09-­‑2 i20n08-­‑1 i20n08-­‑2 i21n07-­‑1 i21n07-­‑2 average

Weighted ¡Speedup ¡ Improvement ¡[%]

Heterogeneous ¡Workloads

  • Weighted ¡Speedup ¡and ¡Maximum ¡Slowdown