Skip to contentSkip to conversation

KVM call agenda for 2013-04-09

DISCUSSION Juan Quintela 2 participants 3 messages Apr 8, 2013 – Apr 9, 2013 KVM

lore
Share & tools
lore
#0 lore raw

Hi

Please send in any agenda topics you are interested in.

Later, Juan.

#1 lore raw
Quoted 1 line · Juan Quintela

Hi

Today there is a call, there was agenda but I didn't noticed that it was sent as private mail to me:

Quoted 1 line

From Abel Gordon:

I would like to present a technical report we just published that describes the design and evaluation of the work we did to improve virtual net/block I/O scalability and performance based on vhost and hosting multiple KVM guests.

We started some discussion in the qemu-mailing list about this work and dataplane:

http://lists.gnu.org/archive/html/qemu-devel/2013-02/msg02702.html
http://lists.gnu.org/archive/html/qemu-devel/2013-03/msg00028.html

The report can be downloaded from the following link: http://goo.gl/RKppy

(full link:

http://domino.research.ibm.com/library/cyberdig.nsf/1e4115aea78b6e7c85256b360066f0d4/479e3578ed05bfac85257b4200427735!OpenDocument&Highlight=0,h-0319

)

#2 lore raw
In reply to Juan Quintela

Meeting notes on Abel's presentation:

Aim: improve vhost scalability

Shared vhost thread
==============
Problem: Linux scheduler does not see state of virtqueues, cannot make good scheduling decisions
Solution: Shared thread serves multiple VMs and therefore influences "I/O scheduling" instead of kernel thread per vhost device

Exitless communication
=================
* Polling on host to notice guest vring updates without guest pio instruction
* Use CPU affinity to bind vcpus to separate cores and let polling
run on dedicated cores
* Existless Interrupt (ELI) or future hardware APIC virtualization
feature to inject virtual interrupts
without vmexit and EOI

See paper for performance results (impressive numbers):
http://domino.research.ibm.com/library/cyberdig.nsf/papers/479E3578ED05BFAC85257B4200427735/$File/h-0319.pdf

Abel will publish rebased code on GitHub but does not have time to upstream them.

The next step: QEMU/KVM community can digest the paper + patches and decide on ideas to upstream.