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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).