All of lore.kernel.org
 help / color / mirror / Atom feed
From: piaojun <piaojun@huawei.com>
To: Stefan Hajnoczi <stefanha@redhat.com>, <virtio-fs@redhat.com>,
	<qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [Virtio-fs] [PATCH 0/4] virtiofsd: multithreading preparation part 3
Date: Thu, 8 Aug 2019 16:10:00 +0800	[thread overview]
Message-ID: <5D4BD8D8.5080402@huawei.com> (raw)
In-Reply-To: <20190807180355.GA22758@stefanha-x1.localdomain>

Hi Stefan,

From my test, your patch set of multithreading improves iops greatly as
below:

Guest configuration:
8 vCPU
8GB RAM
Linux 5.1 (vivek-aug-06-2019)

Host configuration:
Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz (8 cores x 4 threads)
32GB RAM
Linux 3.10.0
EXT4 + LVM + local HDD

---
Before:
# fio -direct=1 -time_based -iodepth=64 -rw=randread -ioengine=libaio -bs=4k -size=1G -numjob=1 -runtime=30 -group_reporting -name=file -filename=/mnt/virtiofs/file
Jobs: 1 (f=1): [r(1)] [100.0% done] [1177KB/0KB/0KB /s] [294/0/0 iops] [eta 00m:00s]
file: (groupid=0, jobs=1): err= 0: pid=6037: Thu Aug  8 23:18:59 2019
  read : io=35148KB, bw=1169.9KB/s, iops=292, runt= 30045msec

After:
Jobs: 1 (f=1): [r(1)] [100.0% done] [6246KB/0KB/0KB /s] [1561/0/0 iops] [eta 00m:00s]
file: (groupid=0, jobs=1): err= 0: pid=5850: Thu Aug  8 23:21:22 2019
  read : io=191216KB, bw=6370.7KB/s, iops=1592, runt= 30015msec
---

But there is no iops improvment when I change from HDD to ramdisk. I
guess this is because ramdisk has no iodepth.

Thanks,
Jun

On 2019/8/8 2:03, Stefan Hajnoczi wrote:
> On Thu, Aug 01, 2019 at 05:54:05PM +0100, Stefan Hajnoczi wrote:
>> Performance
>> -----------
>> Please try these patches out and share your results.
> 
> Here are the performance numbers:
> 
>   Threadpool | iodepth | iodepth
>      size    |    1    |   64
>   -----------+---------+--------
>   None       |   4451  |  4876
>   1          |   4360  |  4858
>   64         |   4359  | 33,266
> 
> A graph is available here:
> https://vmsplice.net/~stefan/virtiofsd-threadpool-performance.png
> 
> Summary:
> 
>  * iodepth=64 performance is increased by 6.8 times.
>  * iodepth=1 performance degrades by 2%.
>  * DAX is bottlenecked by QEMU's single-threaded
>    VHOST_USER_SLAVE_FS_MAP/UNMAP handler.
> 
> Threadpool size "none" is virtiofsd commit 813a824b707 ("virtiofsd: use
> fuse_lowlevel_is_virtio() in fuse_session_destroy()") without any of the
> multithreading preparation patches.  I benchmarked this to check whether
> the patches introduce a regression for iodepth=1.  They do, but it's
> only around 2%.
> 
> I also ran with DAX but found there was not much difference between
> iodepth=1 and iodepth=64.  This might be because the host mmap(2)
> syscall becomes the bottleneck and a serialization point.  QEMU only
> processes one VHOST_USER_SLAVE_FS_MAP/UNMAP at a time.  If we want to
> accelerate DAX it may be necessary to parallelize mmap, assuming the
> host kernel can do them in parallel on a single file.  This performance
> optimization is future work and not directly related to this patch
> series.
> 
> The following fio job was run with cache=none and no DAX:
> 
>   [global]
>   runtime=60
>   ramp_time=30
>   filename=/var/tmp/fio.dat
>   direct=1
>   rw=randread
>   bs=4k
>   size=4G
>   ioengine=libaio
>   iodepth=1
> 
>   [read]
> 
> Guest configuration:
> 1 vCPU
> 4 GB RAM
> Linux 5.1 (vivek-aug-06-2019)
> 
> Host configuration:
> Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz (2 cores x 2 threads)
> 8 GB RAM
> Linux 5.1.20-300.fc30.x86_64
> XFS + dm-thin + dm-crypt
> Toshiba THNSFJ256GDNU (256 GB SATA SSD)
> 
> Stefan
> 
> 
> 
> _______________________________________________
> Virtio-fs mailing list
> Virtio-fs@redhat.com
> https://www.redhat.com/mailman/listinfo/virtio-fs
> 


WARNING: multiple messages have this Message-ID (diff)
From: piaojun <piaojun@huawei.com>
To: Stefan Hajnoczi <stefanha@redhat.com>,
	virtio-fs@redhat.com, qemu-devel@nongnu.org
Subject: Re: [Virtio-fs] [PATCH 0/4] virtiofsd: multithreading preparation part 3
Date: Thu, 8 Aug 2019 16:10:00 +0800	[thread overview]
Message-ID: <5D4BD8D8.5080402@huawei.com> (raw)
In-Reply-To: <20190807180355.GA22758@stefanha-x1.localdomain>

Hi Stefan,

>From my test, your patch set of multithreading improves iops greatly as
below:

Guest configuration:
8 vCPU
8GB RAM
Linux 5.1 (vivek-aug-06-2019)

Host configuration:
Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz (8 cores x 4 threads)
32GB RAM
Linux 3.10.0
EXT4 + LVM + local HDD

---
Before:
# fio -direct=1 -time_based -iodepth=64 -rw=randread -ioengine=libaio -bs=4k -size=1G -numjob=1 -runtime=30 -group_reporting -name=file -filename=/mnt/virtiofs/file
Jobs: 1 (f=1): [r(1)] [100.0% done] [1177KB/0KB/0KB /s] [294/0/0 iops] [eta 00m:00s]
file: (groupid=0, jobs=1): err= 0: pid=6037: Thu Aug  8 23:18:59 2019
  read : io=35148KB, bw=1169.9KB/s, iops=292, runt= 30045msec

After:
Jobs: 1 (f=1): [r(1)] [100.0% done] [6246KB/0KB/0KB /s] [1561/0/0 iops] [eta 00m:00s]
file: (groupid=0, jobs=1): err= 0: pid=5850: Thu Aug  8 23:21:22 2019
  read : io=191216KB, bw=6370.7KB/s, iops=1592, runt= 30015msec
---

But there is no iops improvment when I change from HDD to ramdisk. I
guess this is because ramdisk has no iodepth.

Thanks,
Jun

On 2019/8/8 2:03, Stefan Hajnoczi wrote:
> On Thu, Aug 01, 2019 at 05:54:05PM +0100, Stefan Hajnoczi wrote:
>> Performance
>> -----------
>> Please try these patches out and share your results.
> 
> Here are the performance numbers:
> 
>   Threadpool | iodepth | iodepth
>      size    |    1    |   64
>   -----------+---------+--------
>   None       |   4451  |  4876
>   1          |   4360  |  4858
>   64         |   4359  | 33,266
> 
> A graph is available here:
> https://vmsplice.net/~stefan/virtiofsd-threadpool-performance.png
> 
> Summary:
> 
>  * iodepth=64 performance is increased by 6.8 times.
>  * iodepth=1 performance degrades by 2%.
>  * DAX is bottlenecked by QEMU's single-threaded
>    VHOST_USER_SLAVE_FS_MAP/UNMAP handler.
> 
> Threadpool size "none" is virtiofsd commit 813a824b707 ("virtiofsd: use
> fuse_lowlevel_is_virtio() in fuse_session_destroy()") without any of the
> multithreading preparation patches.  I benchmarked this to check whether
> the patches introduce a regression for iodepth=1.  They do, but it's
> only around 2%.
> 
> I also ran with DAX but found there was not much difference between
> iodepth=1 and iodepth=64.  This might be because the host mmap(2)
> syscall becomes the bottleneck and a serialization point.  QEMU only
> processes one VHOST_USER_SLAVE_FS_MAP/UNMAP at a time.  If we want to
> accelerate DAX it may be necessary to parallelize mmap, assuming the
> host kernel can do them in parallel on a single file.  This performance
> optimization is future work and not directly related to this patch
> series.
> 
> The following fio job was run with cache=none and no DAX:
> 
>   [global]
>   runtime=60
>   ramp_time=30
>   filename=/var/tmp/fio.dat
>   direct=1
>   rw=randread
>   bs=4k
>   size=4G
>   ioengine=libaio
>   iodepth=1
> 
>   [read]
> 
> Guest configuration:
> 1 vCPU
> 4 GB RAM
> Linux 5.1 (vivek-aug-06-2019)
> 
> Host configuration:
> Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz (2 cores x 2 threads)
> 8 GB RAM
> Linux 5.1.20-300.fc30.x86_64
> XFS + dm-thin + dm-crypt
> Toshiba THNSFJ256GDNU (256 GB SATA SSD)
> 
> Stefan
> 
> 
> 
> _______________________________________________
> Virtio-fs mailing list
> Virtio-fs@redhat.com
> https://www.redhat.com/mailman/listinfo/virtio-fs
> 


  parent reply	other threads:[~2019-08-08  8:10 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-01 16:54 [Qemu-devel] [PATCH 0/4] virtiofsd: multithreading preparation part 3 Stefan Hajnoczi
2019-08-01 16:54 ` [Virtio-fs] " Stefan Hajnoczi
2019-08-01 16:54 ` [Qemu-devel] [PATCH 1/4] virtiofsd: process requests in a thread pool Stefan Hajnoczi
2019-08-01 16:54   ` [Virtio-fs] " Stefan Hajnoczi
2019-08-05 12:02   ` [Qemu-devel] " Dr. David Alan Gilbert
2019-08-05 12:02     ` [Virtio-fs] " Dr. David Alan Gilbert
2019-08-07  9:35     ` [Qemu-devel] " Stefan Hajnoczi
2019-08-07  9:35       ` [Virtio-fs] " Stefan Hajnoczi
2019-08-01 16:54 ` [Qemu-devel] [PATCH 2/4] virtiofsd: prevent FUSE_INIT/FUSE_DESTROY races Stefan Hajnoczi
2019-08-01 16:54   ` [Virtio-fs] " Stefan Hajnoczi
2019-08-05 12:26   ` [Qemu-devel] " Dr. David Alan Gilbert
2019-08-05 12:26     ` [Virtio-fs] " Dr. David Alan Gilbert
2019-08-01 16:54 ` [Qemu-devel] [PATCH 3/4] virtiofsd: fix lo_destroy() resource leaks Stefan Hajnoczi
2019-08-01 16:54   ` [Virtio-fs] " Stefan Hajnoczi
2019-08-05 15:17   ` [Qemu-devel] " Dr. David Alan Gilbert
2019-08-05 15:17     ` [Virtio-fs] " Dr. David Alan Gilbert
2019-08-05 18:57     ` [Qemu-devel] " Dr. David Alan Gilbert
2019-08-05 18:57       ` [Virtio-fs] " Dr. David Alan Gilbert
2019-08-06 18:58       ` [Qemu-devel] " Dr. David Alan Gilbert
2019-08-06 18:58         ` [Virtio-fs] " Dr. David Alan Gilbert
2019-08-07  9:41       ` [Qemu-devel] " Stefan Hajnoczi
2019-08-07  9:41         ` [Virtio-fs] " Stefan Hajnoczi
2019-08-01 16:54 ` [Qemu-devel] [PATCH 4/4] virtiofsd: add --thread-pool-size=NUM option Stefan Hajnoczi
2019-08-01 16:54   ` [Virtio-fs] " Stefan Hajnoczi
2019-08-05  2:52 ` [Qemu-devel] [Virtio-fs] [PATCH 0/4] virtiofsd: multithreading preparation part 3 piaojun
2019-08-05  2:52   ` piaojun
2019-08-05  8:01   ` [Qemu-devel] " Stefan Hajnoczi
2019-08-05  8:01     ` [Virtio-fs] [Qemu-devel] " Stefan Hajnoczi
2019-08-05  9:40     ` [Qemu-devel] [Virtio-fs] " piaojun
2019-08-05  9:40       ` [Virtio-fs] [Qemu-devel] " piaojun
2019-08-07 18:03 ` Stefan Hajnoczi
2019-08-07 18:03   ` [Virtio-fs] " Stefan Hajnoczi
2019-08-07 20:57   ` [Qemu-devel] " Vivek Goyal
2019-08-07 20:57     ` Vivek Goyal
2019-08-08  9:02     ` [Qemu-devel] " Stefan Hajnoczi
2019-08-08  9:02       ` Stefan Hajnoczi
2019-08-08  9:53       ` [Qemu-devel] " Dr. David Alan Gilbert
2019-08-08  9:53         ` Dr. David Alan Gilbert
2019-08-08 12:53         ` [Qemu-devel] " Vivek Goyal
2019-08-08 12:53           ` Vivek Goyal
2019-08-09  8:23           ` [Qemu-devel] " Stefan Hajnoczi
2019-08-09  8:23             ` Stefan Hajnoczi
2019-08-10 21:35           ` [Qemu-devel] " Liu Bo
2019-08-10 21:35             ` Liu Bo
2019-08-09  8:21         ` [Qemu-devel] " Stefan Hajnoczi
2019-08-09  8:21           ` Stefan Hajnoczi
2019-08-10 21:34           ` [Qemu-devel] " Liu Bo
2019-08-10 21:34             ` Liu Bo
2019-08-11  2:26           ` [Qemu-devel] " piaojun
2019-08-11  2:26             ` piaojun
2019-08-12 10:05             ` [Qemu-devel] " Stefan Hajnoczi
2019-08-12 10:05               ` Stefan Hajnoczi
2019-08-12 11:58               ` [Qemu-devel] " piaojun
2019-08-12 11:58                 ` piaojun
2019-08-12 12:51                 ` [Qemu-devel] " Dr. David Alan Gilbert
2019-08-12 12:51                   ` Dr. David Alan Gilbert
2019-08-08  8:10   ` piaojun [this message]
2019-08-08  8:10     ` piaojun
2019-08-08  9:53     ` [Qemu-devel] " Stefan Hajnoczi
2019-08-08  9:53       ` 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=5D4BD8D8.5080402@huawei.com \
    --to=piaojun@huawei.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    --cc=virtio-fs@redhat.com \
    /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.