Interrupt Coalescing in Xen with Scheduler Awareness Michael Peirce - - PowerPoint PPT Presentation

interrupt coalescing in xen
SMART_READER_LITE
LIVE PREVIEW

Interrupt Coalescing in Xen with Scheduler Awareness Michael Peirce - - PowerPoint PPT Presentation

Interrupt Coalescing in Xen with Scheduler Awareness Michael Peirce & Kevin Boos Outline Background Hypothesis vIC-style Interrupt Coalescing Adding Scheduler Awareness Evaluation 2 Background Xen split block


slide-1
SLIDE 1

Interrupt Coalescing in Xen

with Scheduler Awareness

Michael Peirce & Kevin Boos

slide-2
SLIDE 2

Outline

  • Background
  • Hypothesis
  • vIC-style Interrupt Coalescing
  • Adding Scheduler Awareness
  • Evaluation

2

slide-3
SLIDE 3

Background

Xen split block drivers

3

slide-4
SLIDE 4

Background: Xen block drivers

dom0 domU guest Xen hypervisor blkback blkfront

4

driver

slide-5
SLIDE 5

Background: ring buffers

dom0 blkback

RSP2 RSP3 RSP1 REQ4 REQ5 REQ6

ring buffer (in shared page) domU guest blkfront

response consumer request producer response producer request consumer 5

driver

slide-6
SLIDE 6

Background: interrupt event channels

dom0 blkback domU guest blkfront

interrupt: requests pending interrupt: responses pending

Xen hypervisor

6

driver

slide-7
SLIDE 7

Focus on blkback

dom0 domU guest blkfront

interrupt: requests pending

Xen hypervisor driver blkback

interrupt: responses pending

7

slide-8
SLIDE 8

Hypothesis

8

slide-9
SLIDE 9

Hypothesis

1) Coalescing interrupts in Xen will increase throughput

  • f block devices at minor latency cost (vIC)

fewer interrupts reduces CPU overhead

2) Scheduler awareness will improve upon existing coalescing policies by reducing latency ○

less coalescing towards end of timeslice

minimal reduction in throughput

9

slide-10
SLIDE 10

Conventional Interrupt Coalescing

VMware vIC

10

slide-11
SLIDE 11

VMware-style Coalescing (vIC)

  • Interrupt coalescing is absent in Xen
  • Added conventional coalescing based on VMware’s vIC
  • Interrupt delivery ratio based on configurable parameters:

○ IOPS threshold ○ CIF threshold ○ (Epoch period)

  • Implemented in dom0’s kernel, in xen_blkback module

○ On each block_io completion event, decide whether to deliver interrupt

11

slide-12
SLIDE 12

vIC Implementation Diagram

dom0 domU guest blkfront

interrupt: requests pending

Xen hypervisor measure IOPS & CIF blkback driver

coalesce

interrupt: responses pending

12

slide-13
SLIDE 13

Default Interrupt Delivery (no coalescing)

Device interrupts from Hypervisor Dom0 time 20ms 30ms

Core 1 Core 2

Guest 1 Timeslice Guest 2 Timeslice 10 interrupts

13

slide-14
SLIDE 14

Increasing Disk Throughput in vIC

Dom0 time 20ms 30ms

Core 1 Core 2

Guest 1 Timeslice Guest 2 Timeslice 5 interrupts

14

Device interrupts from Hypervisor

slide-15
SLIDE 15

Scheduler Awareness

15

slide-16
SLIDE 16

Latency Problems in vIC

Dom0 time 20ms 30ms

Core 1 Core 2

Guest 1 Timeslice Guest 2 Timeslice

16

Device interrupts from Hypervisor

slide-17
SLIDE 17

Reducing Latency

Dom0 time 20ms 30ms

Core 1 Core 2

Guest 1 Timeslice Guest 2 Timeslice

17

Device interrupts from Hypervisor

slide-18
SLIDE 18

Hybrid approach: vIC + scheduler awareness

  • Should we use a separate interrupt delivery policy

based on scheduler info alone?

○ No, too coarse-grained and unintelligent

  • Use scheduler info to configure vIC’s parameters & ratio
  • Hard guarantee that interrupts will be delivered

right at the very end of a timeslice

○ “end of timeslice” cutoff is configurable

18

slide-19
SLIDE 19

Exposing scheduler info from hypervisor

  • Easy way: add hypercall to retrieve scheduler info

○ Pros: easy to implement, info generated on demand ○ Cons: high overhead, long latencies → stale info

  • Hard way: shared memory region with dom0

○ Pros: info is fresh, available immediately ○ Cons: info is updated constantly, very difficult to implement

19

slide-20
SLIDE 20

Implementing shared scheduler info

  • Xen allocates a shared page

for each domain when it boots

○ boot info, arch-specific details, interrupt masks/bit vectors

  • Added scheduler info to shared page

○ One per domain (except idle & dom0)

Only visible in dom0

Updated in hypervisor’s schedule()

  • Much difficulty with time synchronization

20

slide-21
SLIDE 21

Scheduler Awareness Implementation Diagram

dom0 domU guest blkfront

interrupt: requests pending

Xen hypervisor blkback

interrupt: responses pending

driver

coalesce

measure IOPS & CIF

scheduler

21

slide-22
SLIDE 22

Scheduler Awareness Policy

We choose to deliver an interrupt when: remaining time in timeslice < 1 (Ratio * IOPS)

Dom0

22

slide-23
SLIDE 23

Evaluation

23

slide-24
SLIDE 24

Evaluation Setup

  • Default credit scheduler enabled
  • dom0 pinned to two CPU cores, reserved for dom0 only
  • All guests pinned to the same single core

○ Eliminates effects of migration ○ Imitates guest CPU contention on high-density servers

  • Tools to generate disk workload:

○ Copy files with dd, small block size to create more I/O requests ○ Custom interrupt injection tool

24

slide-25
SLIDE 25

Evaluation Questions

  • Can we achieve higher throughput

with minimal latency?

  • Can we achieve the same increased

throughput as vIC with less latency?

vIC scheduler awareness

25

slide-26
SLIDE 26
  • Copy files using dd tool with small block size of 8 & 512 bytes

○ Measure execution time of 1GB file transfer

Throughput Measurement

26

slide-27
SLIDE 27

Throughput Results

27

One guest performing I/O, others hogging CPU

slide-28
SLIDE 28

Throughput Results

28

All guests performing I/O, all guests hogging CPU

slide-29
SLIDE 29
  • Instrumented frontend block driver in the guest kernel

○ Assign (guest-specific) unique ID to each request ○ Start timer when request is submitted ○ End timer when response is received

Latency Measurement

29

slide-30
SLIDE 30

Latency Results

30

slide-31
SLIDE 31

Conclusion

31

slide-32
SLIDE 32

Concluding Remarks

  • As expected, interrupt coalescing does increase throughput
  • Scheduler awareness reduces latency while maintaining

the increased throughput

  • Overall effects are less significant than expected

○ Need more demanding test environment

  • Future work: change beginning of timeslice behavior
  • Our experience developing on Xen was mediocre

○ Tedious, slow, constant reboots ○ Multiple independent code bases (dom0, xen, domU) ○ Limited debug logs, no post-crash log ○ Toolset support and networking is a nightmare

32