Skip to contentSkip to conversation

vhost: a kernel-level virtio server

PATCH Superseded Michael S. Tsirkin 2 participants 8 messages Aug 13, 2009 – Aug 20, 2009

Subsystems (4)

v3 of 9 Superseded Latest is v9 →

lore
Share & tools
lore
#0 lore raw

v3 cover vhost: a kernel-level virtio server

This implements vhost: a kernel-level backend for virtio, The main motivation for this work is to reduce virtualization overhead for virtio by removing system calls on data path, without guest changes. For virtio-net, this removes up to 4 system calls per packet: vm exit for kick, reentry for kick, iothread wakeup for packet, interrupt injection for packet.

Some more detailed description attached to the patch itself.

The patches are against 2.6.31-rc4. I'd like them to go into linux-next and down the road 2.6.32 if possible. Please comment.

Changelog from v2:
- Comments on RCU usage
- Compat ioctl support
- Make variable static
- Copied more idiomatic english from Rusty

Changes from v1:
- Move use_mm/unuse_mm from fs/aio.c to mm instead of copying.
- Reorder code to avoid need for forward declarations
- Kill a couple of debugging printks

Michael S. Tsirkin (2):
mm: export use_mm/unuse_mm to modules
vhost_net: a kernel-level virtio server

 MAINTAINERS                 |   10 +
 arch/x86/kvm/Kconfig        |    1 +
 drivers/Makefile            |    1 +
 drivers/vhost/Kconfig       |   11 +
 drivers/vhost/Makefile      |    2 +
 drivers/vhost/net.c         |  429 ++++++++++++++++++++++++++++
 drivers/vhost/vhost.c       |  663 +++++++++++++++++++++++++++++++++++++++++++
 drivers/vhost/vhost.h       |  108 +++++++
 fs/aio.c                    |   47 +---
 include/linux/Kbuild        |    1 +
 include/linux/miscdevice.h  |    1 +
 include/linux/mmu_context.h |    9 +
 include/linux/vhost.h       |  100 +++++++
 mm/Makefile                 |    2 +-
 mm/mmu_context.c            |   58 ++++
 15 files changed, 1396 insertions(+), 47 deletions(-)
 create mode 100644 drivers/vhost/Kconfig
 create mode 100644 drivers/vhost/Makefile
 create mode 100644 drivers/vhost/net.c
 create mode 100644 drivers/vhost/vhost.c
 create mode 100644 drivers/vhost/vhost.h
 create mode 100644 include/linux/mmu_context.h
 create mode 100644 include/linux/vhost.h
 create mode 100644 mm/mmu_context.c

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

#1 lore raw
Quoted 2 lines · Michael S. Tsirkin

The patches are against 2.6.31-rc4. I'd like them to go into linux-next and down the road 2.6.32 if possible. Please comment.

Hi Michael,

Just wanted to make sure with you how this can be tested, is 2.6.31-rc4 plus these two patches enough to form the kernel part? I wasn't sure if both the irqfd/iosignalfd are needed and if both are merged to Linus tree...

As for the user space part, should I use upstream qemu plus patches 1-4?

Or.

#2 lore raw
Quoted 9 lines · Or Gerlitz
Quoted 2 lines · Michael S. Tsirkin

The patches are against 2.6.31-rc4. I'd like them to go into linux-next and down the road 2.6.32 if possible. Please comment.

Hi Michael,

Just wanted to make sure with you how this can be tested, is 2.6.31-rc4 plus these two patches enough to form the kernel part? I wasn't sure if both the irqfd/iosignalfd are needed and if both are merged to Linus tree...

No, these patches are on top of Avi's kvm.git

Quoted 1 line

As for the user space part, should I use upstream qemu plus patches 1-4?

qemu-kvm

Quoted 1 line

Or.

#3 lore raw
Quoted 2 lines · Michael S. Tsirkin

No, these patches are on top of Avi's kvm.git

so are they on top of some branch in Avi's kvm.git which is planned to be merged for 2.6.32? what branch should I use?

Or.

#4 lore raw
Quoted 5 lines · Or Gerlitz
Quoted 2 lines · Michael S. Tsirkin

No, these patches are on top of Avi's kvm.git

so are they on top of some branch in Avi's kvm.git which is planned to be merged for 2.6.32? what branch should I use?

Yes. master

Quoted 1 line

Or.

#5 lore raw
Quoted 1 line · Michael S. Tsirkin

Yes. master

okay, will get testing this later next week. Any chance you can provide some packet-per-second numbers (netperf udp stream with small packets)?

Or.

#6 lore raw
Quoted 6 lines · Or Gerlitz
Quoted 1 line · Michael S. Tsirkin

Yes. master

okay, will get testing this later next week. Any chance you can provide some packet-per-second numbers (netperf udp stream with small packets)?

Or.

Don't expect it to be good yet. I'm working on vm exit mitigation now, before that only latency is worth checking.

Signature · 1 line
MST
author Acked-by Andrea Arcangeli
#7 lore raw
In reply to Or Gerlitz
Quoted 6 lines · Or Gerlitz
Quoted 1 line · Michael S. Tsirkin

Yes. master

okay, will get testing this later next week. Any chance you can provide some packet-per-second numbers (netperf udp stream with small packets)?

Or.

If you do, maybe you should apply the following patch on top (seems to save 2 atomics in about 50% of cases for me).

---

mm: reduce atomic use on use_mm fast path

When mm switched to matches that of active mm, we don't need to increment and then drop the mm count. Making that conditional reduces contention on that cache line on SMP systems.

mm/mmu_context.c +6 -3
index 9989c2f..0777654 100644
@@ -27,13 +27,16 @@ void use_mm(struct mm_struct *mm)
 
 	task_lock(tsk);
 	active_mm = tsk->active_mm;
-	atomic_inc(&mm->mm_count);
+	if (active_mm != mm) {
+		atomic_inc(&mm->mm_count);
+		tsk->active_mm = mm;
+	}
 	tsk->mm = mm;
-	tsk->active_mm = mm;
 	switch_mm(active_mm, mm, tsk);
 	task_unlock(tsk);
 
-	mmdrop(active_mm);
+	if (active_mm != mm)
+		mmdrop(active_mm);
 }
 EXPORT_SYMBOL_GPL(use_mm);