From: Stefan Hajnoczi <stefanha@redhat.com>
To: Andrey Zhadchenko <andrey.zhadchenko@virtuozzo.com>
Cc: qemu-block@nongnu.org, qemu-devel@nongnu.org, kwolf@redhat.com,
hreitz@redhat.com, mst@redhat.com, den@virtuozzo.com
Subject: Re: [RFC patch 0/1] block: vhost-blk backend
Date: Wed, 5 Oct 2022 11:30:27 -0400 [thread overview]
Message-ID: <Yz2jE7N65GUAEIBg@fedora> (raw)
In-Reply-To: <ae1a9e07-b457-7208-3bff-f53c5de9c3e8@virtuozzo.com>
[-- Attachment #1: Type: text/plain, Size: 4189 bytes --]
On Wed, Oct 05, 2022 at 01:28:14PM +0300, Andrey Zhadchenko wrote:
>
>
> On 10/4/22 21:26, Stefan Hajnoczi wrote:
> > On Mon, Jul 25, 2022 at 11:55:26PM +0300, Andrey Zhadchenko wrote:
> > > Although QEMU virtio-blk is quite fast, there is still some room for
> > > improvements. Disk latency can be reduced if we handle virito-blk requests
> > > in host kernel so we avoid a lot of syscalls and context switches.
> > >
> > > The biggest disadvantage of this vhost-blk flavor is raw format.
> > > Luckily Kirill Thai proposed device mapper driver for QCOW2 format to attach
> > > files as block devices: https://www.spinics.net/lists/kernel/msg4292965.html
> > >
> > > Also by using kernel modules we can bypass iothread limitation and finaly scale
> > > block requests with cpus for high-performance devices. This is planned to be
> > > implemented in next version.
> > >
> > > Linux kernel module part:
> > > https://lore.kernel.org/kvm/20220725202753.298725-1-andrey.zhadchenko@virtuozzo.com/
> > >
> > > test setups and results:
> > > fio --direct=1 --rw=randread --bs=4k --ioengine=libaio --iodepth=128
> >
> > > QEMU drive options: cache=none
> > > filesystem: xfs
> >
> > Please post the full QEMU command-line so it's clear exactly what this
> > is benchmarking.
>
> The full command for vhost is this:
> qemu-system-x86_64 \
> -kernel bzImage -nographic -append "console=ttyS0 root=/dev/sdb rw
> systemd.unified_cgroup_hierarchy=0 nokaslr" \
> -m 1024 -s --enable-kvm -smp $2 \
> -drive id=main_drive,file=debian_sid.img,media=disk,format=raw \
> -drive id=vhost_drive,file=$1,media=disk,format=raw,if=none \
No cache=none because vhost-blk directly submits bios in the kernel?
> -device vhost-blk-pci,drive=vhost_drive,num-threads=$3
>
> (num-threads option for vhost-blk-pci was not used)
>
> For virtio I used this:
> qemu-system-x86_64 \
> -kernel bzImage -nographic -append "console=ttyS0 root=/dev/sdb rw
> systemd.unified_cgroup_hierarchy=0 nokaslr" \
> -m 1024 -s --enable-kvm -smp $2 \
> -drive file=debian_sid.img,media=disk \
> -drive file=$1,media=disk,if=virtio,cache=none,if=none,id=d1,aio=threads\
> -device virtio-blk-pci,drive=d1
>
> >
> > A preallocated raw image file is a good baseline with:
> >
> > --object iothread,id=iothread0 \
> > --blockdev file,filename=test.img,cache.direct=on,aio=native,node-name=drive0 > --device virtio-blk-pci,drive=drive0,iothread=iothread0
> The image I used was preallocated qcow2 image set up with dm-qcow2 because
> this vhost-blk version directly uses bio interface and can't work with
> regular files.
I see.
>
> >
> > (BTW QEMU's default vq size is 256 descriptors and the number of vqs is
> > the number of vCPUs.)
> >
> > >
> > > SSD:
> > > | randread, IOPS | randwrite, IOPS |
> > > Host | 95.8k | 85.3k |
> > > QEMU virtio | 57.5k | 79.4k |
>
> Adding iothread0 and using raw file instead of qcow2 + dm-qcow2 setup brings
> the numbers to
> | 60.4k | 84.3k |
>
> > > QEMU vhost-blk | 95.6k | 84.3k |
> > >
> > > RAMDISK (vq == vcpu):
> >
> > With fio numjobs=vcpu here?
>
> Yes
>
> >
> > > | randread, IOPS | randwrite, IOPS |
> > > virtio, 1vcpu | 123k | 129k |
> > > virtio, 2vcpu | 253k (??) | 250k (??) |
> >
> > QEMU's aio=threads (default) gets around the single IOThread. It beats
> > aio=native for this reason in some cases. Were you using aio=native or
> > aio=threads?
>
> At some point of time I started to specify aio=threads (and before that I
> did not use this option). I am not sure when exactly. I will re-measure all
> cases for the next submission.
aio=native is usually recommended. aio=threads is less optimized.
aio=native should have lower latency than aio=threads although it scales
worse on hosts with free CPUs because it's limited to a single thread.
>
> >
> > > virtio, 4vcpu | 158k | 154k |
> > > vhost-blk, 1vcpu | 110k | 113k |
> > > vhost-blk, 2vcpu | 247k | 252k |
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2022-10-05 15:33 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-25 20:55 [RFC patch 0/1] block: vhost-blk backend Andrey Zhadchenko via
2022-07-25 20:55 ` [RFC PATCH 1/1] block: add " Andrey Zhadchenko via
2022-10-04 18:45 ` Stefan Hajnoczi
2022-10-05 13:06 ` Andrey Zhadchenko
2022-10-05 15:50 ` Stefan Hajnoczi
2022-07-26 13:51 ` [RFC patch 0/1] block: " Michael S. Tsirkin
2022-07-26 14:15 ` Denis V. Lunev
2022-07-27 13:06 ` Stefano Garzarella
2022-07-28 5:28 ` Andrey Zhadchenko
2022-07-28 15:40 ` Stefano Garzarella
2022-10-04 18:13 ` Stefan Hajnoczi
2022-10-05 9:14 ` Andrey Zhadchenko
2022-10-05 15:18 ` Stefan Hajnoczi
2022-10-04 18:26 ` Stefan Hajnoczi
2022-10-05 10:28 ` Andrey Zhadchenko
2022-10-05 15:30 ` Stefan Hajnoczi [this message]
2022-10-04 19:00 ` Stefan Hajnoczi
2022-10-05 11:50 ` Andrey Zhadchenko
2022-10-05 15:40 ` Stefan Hajnoczi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Yz2jE7N65GUAEIBg@fedora \
--to=stefanha@redhat.com \
--cc=andrey.zhadchenko@virtuozzo.com \
--cc=den@virtuozzo.com \
--cc=hreitz@redhat.com \
--cc=kwolf@redhat.com \
--cc=mst@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.