From: Vivek Goyal <vgoyal@redhat.com> To: Christian Schoenebeck <qemu_oss@crudebyte.com> Cc: "Venegas Munoz, Jose Carlos" <jose.carlos.venegas.munoz@intel.com>, qemu-devel@nongnu.org, "cdupontd@redhat.com" <cdupontd@redhat.com>, virtio-fs-list <virtio-fs@redhat.com>, Stefan Hajnoczi <stefanha@redhat.com>, "Shinde, Archana M" <archana.m.shinde@intel.com>, "Dr. David Alan Gilbert" <dgilbert@redhat.com> Subject: Re: virtiofs vs 9p performance(Re: tools/virtiofs: Multi threading seems to hurt performance) Date: Tue, 29 Sep 2020 09:49:42 -0400 [thread overview] Message-ID: <20200929134942.GC220516@redhat.com> (raw) In-Reply-To: <2302525.O3mciSdnpG@silver> On Tue, Sep 29, 2020 at 03:28:06PM +0200, Christian Schoenebeck wrote: > On Dienstag, 29. September 2020 15:03:25 CEST Vivek Goyal wrote: > > On Sun, Sep 27, 2020 at 02:14:43PM +0200, Christian Schoenebeck wrote: > > > On Freitag, 25. September 2020 20:51:47 CEST Dr. David Alan Gilbert wrote: > > > > * Christian Schoenebeck (qemu_oss@crudebyte.com) wrote: > > > > > On Freitag, 25. September 2020 15:05:38 CEST Dr. David Alan Gilbert > wrote: > > > > > > > > 9p ( mount -t 9p -o trans=virtio kernel /mnt > > > > > > > > -oversion=9p2000.L,cache=mmap,msize=1048576 ) test: (g=0): > > > > > > > > rw=randrw, > > > > > > > > > > > > > > Bottleneck ------------------------------^ > > > > > > > > > > > > > > By increasing 'msize' you would encounter better 9P I/O results. > > > > > > > > > > > > OK, I thought that was bigger than the default; what number should > > > > > > I > > > > > > use? > > > > > > > > > > It depends on the underlying storage hardware. In other words: you > > > > > have to > > > > > try increasing the 'msize' value to a point where you no longer notice > > > > > a > > > > > negative performance impact (or almost). Which is fortunately quite > > > > > easy > > > > > to test on> > > > > > > > > > > guest like: > > > > > dd if=/dev/zero of=test.dat bs=1G count=12 > > > > > time cat test.dat > /dev/null > > > > > > > > > > I would start with an absolute minimum msize of 10MB. I would > > > > > recommend > > > > > something around 100MB maybe for a mechanical hard drive. With a PCIe > > > > > flash > > > > > you probably would rather pick several hundred MB or even more. > > > > > > > > > > That unpleasant 'msize' issue is a limitation of the 9p protocol: > > > > > client > > > > > (guest) must suggest the value of msize on connection to server > > > > > (host). > > > > > Server can only lower, but not raise it. And the client in turn > > > > > obviously > > > > > cannot see host's storage device(s), so client is unable to pick a > > > > > good > > > > > value by itself. So it's a suboptimal handshake issue right now. > > > > > > > > It doesn't seem to be making a vast difference here: > > > > > > > > > > > > > > > > 9p mount -t 9p -o trans=virtio kernel /mnt > > > > -oversion=9p2000.L,cache=mmap,msize=104857600 > > > > > > > > Run status group 0 (all jobs): > > > > READ: bw=62.5MiB/s (65.6MB/s), 62.5MiB/s-62.5MiB/s > > > > (65.6MB/s-65.6MB/s), > > > > > > > > io=3070MiB (3219MB), run=49099-49099msec WRITE: bw=20.9MiB/s (21.9MB/s), > > > > 20.9MiB/s-20.9MiB/s (21.9MB/s-21.9MB/s), io=1026MiB (1076MB), > > > > run=49099-49099msec > > > > > > > > 9p mount -t 9p -o trans=virtio kernel /mnt > > > > -oversion=9p2000.L,cache=mmap,msize=1048576000 > > > > > > > > Run status group 0 (all jobs): > > > > READ: bw=65.2MiB/s (68.3MB/s), 65.2MiB/s-65.2MiB/s > > > > (68.3MB/s-68.3MB/s), > > > > > > > > io=3070MiB (3219MB), run=47104-47104msec WRITE: bw=21.8MiB/s (22.8MB/s), > > > > 21.8MiB/s-21.8MiB/s (22.8MB/s-22.8MB/s), io=1026MiB (1076MB), > > > > run=47104-47104msec > > > > > > > > > > > > Dave > > > > > > Is that benchmark tool honoring 'iounit' to automatically run with max. > > > I/O > > > chunk sizes? What's that benchmark tool actually? And do you also see no > > > improvement with a simple > > > > > > time cat largefile.dat > /dev/null > > > > I am assuming that msize only helps with sequential I/O and not random > > I/O. > > > > Dave is running random read and random write mix and probably that's why > > he is not seeing any improvement with msize increase. > > > > If we run sequential workload (as "cat largefile.dat"), that should > > see an improvement with msize increase. > > > > Thanks > > Vivek > > Depends on what's randomized. If read chunk size is randomized, then yes, you > would probably see less performance increase compared to a simple > 'cat foo.dat'. We are using "fio" for testing and read chunk size is not being randomized. chunk size (block size) is fixed at 4K size for these tests. > > If only the read position is randomized, but the read chunk size honors > iounit, a.k.a. stat's st_blksize (i.e. reading with the most efficient block > size advertised by 9P), then I would assume still seeing a performance > increase. Yes, we are randomizing read position. But there is no notion of looking at st_blksize. Its fixed at 4K. (notice option --bs=4k in fio commandline). > Because seeking is a no/low cost factor in this case. The guest OS > seeking does not transmit a 9p message. The offset is rather passed with any > Tread message instead: > https://github.com/chaos/diod/blob/master/protocol.md > > I mean, yes, random seeks reduce I/O performance in general of course, but in > direct performance comparison, the difference in overhead of the 9p vs. > virtiofs network controller layer is most probably the most relevant aspect if > large I/O chunk sizes are used. > Agreed that large I/O chunk size will help with the perfomance numbers. But idea is to intentonally use smaller I/O chunk size with some of the tests to measure how efficient communication path is. Thanks Vivek
WARNING: multiple messages have this Message-ID (diff)
From: Vivek Goyal <vgoyal@redhat.com> To: Christian Schoenebeck <qemu_oss@crudebyte.com> Cc: "Venegas Munoz, Jose Carlos" <jose.carlos.venegas.munoz@intel.com>, qemu-devel@nongnu.org, "cdupontd@redhat.com" <cdupontd@redhat.com>, virtio-fs-list <virtio-fs@redhat.com>, "Shinde, Archana M" <archana.m.shinde@intel.com> Subject: Re: [Virtio-fs] virtiofs vs 9p performance(Re: tools/virtiofs: Multi threading seems to hurt performance) Date: Tue, 29 Sep 2020 09:49:42 -0400 [thread overview] Message-ID: <20200929134942.GC220516@redhat.com> (raw) In-Reply-To: <2302525.O3mciSdnpG@silver> On Tue, Sep 29, 2020 at 03:28:06PM +0200, Christian Schoenebeck wrote: > On Dienstag, 29. September 2020 15:03:25 CEST Vivek Goyal wrote: > > On Sun, Sep 27, 2020 at 02:14:43PM +0200, Christian Schoenebeck wrote: > > > On Freitag, 25. September 2020 20:51:47 CEST Dr. David Alan Gilbert wrote: > > > > * Christian Schoenebeck (qemu_oss@crudebyte.com) wrote: > > > > > On Freitag, 25. September 2020 15:05:38 CEST Dr. David Alan Gilbert > wrote: > > > > > > > > 9p ( mount -t 9p -o trans=virtio kernel /mnt > > > > > > > > -oversion=9p2000.L,cache=mmap,msize=1048576 ) test: (g=0): > > > > > > > > rw=randrw, > > > > > > > > > > > > > > Bottleneck ------------------------------^ > > > > > > > > > > > > > > By increasing 'msize' you would encounter better 9P I/O results. > > > > > > > > > > > > OK, I thought that was bigger than the default; what number should > > > > > > I > > > > > > use? > > > > > > > > > > It depends on the underlying storage hardware. In other words: you > > > > > have to > > > > > try increasing the 'msize' value to a point where you no longer notice > > > > > a > > > > > negative performance impact (or almost). Which is fortunately quite > > > > > easy > > > > > to test on> > > > > > > > > > > guest like: > > > > > dd if=/dev/zero of=test.dat bs=1G count=12 > > > > > time cat test.dat > /dev/null > > > > > > > > > > I would start with an absolute minimum msize of 10MB. I would > > > > > recommend > > > > > something around 100MB maybe for a mechanical hard drive. With a PCIe > > > > > flash > > > > > you probably would rather pick several hundred MB or even more. > > > > > > > > > > That unpleasant 'msize' issue is a limitation of the 9p protocol: > > > > > client > > > > > (guest) must suggest the value of msize on connection to server > > > > > (host). > > > > > Server can only lower, but not raise it. And the client in turn > > > > > obviously > > > > > cannot see host's storage device(s), so client is unable to pick a > > > > > good > > > > > value by itself. So it's a suboptimal handshake issue right now. > > > > > > > > It doesn't seem to be making a vast difference here: > > > > > > > > > > > > > > > > 9p mount -t 9p -o trans=virtio kernel /mnt > > > > -oversion=9p2000.L,cache=mmap,msize=104857600 > > > > > > > > Run status group 0 (all jobs): > > > > READ: bw=62.5MiB/s (65.6MB/s), 62.5MiB/s-62.5MiB/s > > > > (65.6MB/s-65.6MB/s), > > > > > > > > io=3070MiB (3219MB), run=49099-49099msec WRITE: bw=20.9MiB/s (21.9MB/s), > > > > 20.9MiB/s-20.9MiB/s (21.9MB/s-21.9MB/s), io=1026MiB (1076MB), > > > > run=49099-49099msec > > > > > > > > 9p mount -t 9p -o trans=virtio kernel /mnt > > > > -oversion=9p2000.L,cache=mmap,msize=1048576000 > > > > > > > > Run status group 0 (all jobs): > > > > READ: bw=65.2MiB/s (68.3MB/s), 65.2MiB/s-65.2MiB/s > > > > (68.3MB/s-68.3MB/s), > > > > > > > > io=3070MiB (3219MB), run=47104-47104msec WRITE: bw=21.8MiB/s (22.8MB/s), > > > > 21.8MiB/s-21.8MiB/s (22.8MB/s-22.8MB/s), io=1026MiB (1076MB), > > > > run=47104-47104msec > > > > > > > > > > > > Dave > > > > > > Is that benchmark tool honoring 'iounit' to automatically run with max. > > > I/O > > > chunk sizes? What's that benchmark tool actually? And do you also see no > > > improvement with a simple > > > > > > time cat largefile.dat > /dev/null > > > > I am assuming that msize only helps with sequential I/O and not random > > I/O. > > > > Dave is running random read and random write mix and probably that's why > > he is not seeing any improvement with msize increase. > > > > If we run sequential workload (as "cat largefile.dat"), that should > > see an improvement with msize increase. > > > > Thanks > > Vivek > > Depends on what's randomized. If read chunk size is randomized, then yes, you > would probably see less performance increase compared to a simple > 'cat foo.dat'. We are using "fio" for testing and read chunk size is not being randomized. chunk size (block size) is fixed at 4K size for these tests. > > If only the read position is randomized, but the read chunk size honors > iounit, a.k.a. stat's st_blksize (i.e. reading with the most efficient block > size advertised by 9P), then I would assume still seeing a performance > increase. Yes, we are randomizing read position. But there is no notion of looking at st_blksize. Its fixed at 4K. (notice option --bs=4k in fio commandline). > Because seeking is a no/low cost factor in this case. The guest OS > seeking does not transmit a 9p message. The offset is rather passed with any > Tread message instead: > https://github.com/chaos/diod/blob/master/protocol.md > > I mean, yes, random seeks reduce I/O performance in general of course, but in > direct performance comparison, the difference in overhead of the 9p vs. > virtiofs network controller layer is most probably the most relevant aspect if > large I/O chunk sizes are used. > Agreed that large I/O chunk size will help with the perfomance numbers. But idea is to intentonally use smaller I/O chunk size with some of the tests to measure how efficient communication path is. Thanks Vivek
next prev parent reply other threads:[~2020-09-29 13:51 UTC|newest] Thread overview: 107+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-09-18 21:34 tools/virtiofs: Multi threading seems to hurt performance Vivek Goyal 2020-09-18 21:34 ` [Virtio-fs] " Vivek Goyal 2020-09-21 8:39 ` Stefan Hajnoczi 2020-09-21 8:39 ` [Virtio-fs] " Stefan Hajnoczi 2020-09-21 13:39 ` Vivek Goyal 2020-09-21 13:39 ` [Virtio-fs] " Vivek Goyal 2020-09-21 16:57 ` Stefan Hajnoczi 2020-09-21 16:57 ` [Virtio-fs] " Stefan Hajnoczi 2020-09-21 8:50 ` Dr. David Alan Gilbert 2020-09-21 8:50 ` [Virtio-fs] " Dr. David Alan Gilbert 2020-09-21 13:35 ` Vivek Goyal 2020-09-21 13:35 ` [Virtio-fs] " Vivek Goyal 2020-09-21 14:08 ` Daniel P. Berrangé 2020-09-21 14:08 ` [Virtio-fs] " Daniel P. Berrangé 2020-09-21 15:32 ` Dr. David Alan Gilbert 2020-09-21 15:32 ` [Virtio-fs] " Dr. David Alan Gilbert 2020-09-22 10:25 ` Dr. David Alan Gilbert 2020-09-22 10:25 ` [Virtio-fs] " Dr. David Alan Gilbert 2020-09-22 17:47 ` Vivek Goyal 2020-09-22 17:47 ` [Virtio-fs] " Vivek Goyal 2020-09-24 21:33 ` Venegas Munoz, Jose Carlos 2020-09-24 21:33 ` [Virtio-fs] " Venegas Munoz, Jose Carlos 2020-09-24 22:10 ` virtiofs vs 9p performance(Re: tools/virtiofs: Multi threading seems to hurt performance) Vivek Goyal 2020-09-24 22:10 ` [Virtio-fs] " Vivek Goyal 2020-09-25 8:06 ` virtiofs vs 9p performance Christian Schoenebeck 2020-09-25 8:06 ` [Virtio-fs] " Christian Schoenebeck 2020-09-25 13:13 ` Vivek Goyal 2020-09-25 13:13 ` [Virtio-fs] " Vivek Goyal 2020-09-25 15:47 ` Christian Schoenebeck 2020-09-25 15:47 ` [Virtio-fs] " Christian Schoenebeck 2021-02-19 16:08 ` Can not set high msize with virtio-9p (Was: Re: virtiofs vs 9p performance) Vivek Goyal 2021-02-19 16:08 ` [Virtio-fs] " Vivek Goyal 2021-02-19 17:33 ` Christian Schoenebeck 2021-02-19 17:33 ` [Virtio-fs] " Christian Schoenebeck 2021-02-19 19:01 ` Vivek Goyal 2021-02-19 19:01 ` [Virtio-fs] " Vivek Goyal 2021-02-20 15:38 ` Christian Schoenebeck 2021-02-20 15:38 ` [Virtio-fs] " Christian Schoenebeck 2021-02-22 12:18 ` Greg Kurz 2021-02-22 12:18 ` [Virtio-fs] " Greg Kurz 2021-02-22 15:08 ` Christian Schoenebeck 2021-02-22 15:08 ` [Virtio-fs] " Christian Schoenebeck 2021-02-22 17:11 ` Greg Kurz 2021-02-22 17:11 ` [Virtio-fs] " Greg Kurz 2021-02-23 13:39 ` Christian Schoenebeck 2021-02-23 13:39 ` [Virtio-fs] " Christian Schoenebeck 2021-02-23 14:07 ` Michael S. Tsirkin 2021-02-23 14:07 ` [Virtio-fs] " Michael S. Tsirkin 2021-02-24 15:16 ` Christian Schoenebeck 2021-02-24 15:16 ` [Virtio-fs] " Christian Schoenebeck 2021-02-24 15:43 ` Dominique Martinet 2021-02-24 15:43 ` [Virtio-fs] " Dominique Martinet 2021-02-26 13:49 ` Christian Schoenebeck 2021-02-26 13:49 ` [Virtio-fs] " Christian Schoenebeck 2021-02-27 0:03 ` Dominique Martinet 2021-02-27 0:03 ` [Virtio-fs] " Dominique Martinet 2021-03-03 14:04 ` Christian Schoenebeck 2021-03-03 14:04 ` [Virtio-fs] " Christian Schoenebeck 2021-03-03 14:50 ` Dominique Martinet 2021-03-03 14:50 ` [Virtio-fs] " Dominique Martinet 2021-03-05 14:57 ` Christian Schoenebeck 2021-03-05 14:57 ` [Virtio-fs] " Christian Schoenebeck 2020-09-25 12:41 ` virtiofs vs 9p performance(Re: tools/virtiofs: Multi threading seems to hurt performance) Dr. David Alan Gilbert 2020-09-25 12:41 ` [Virtio-fs] " Dr. David Alan Gilbert 2020-09-25 13:04 ` Christian Schoenebeck 2020-09-25 13:04 ` [Virtio-fs] " Christian Schoenebeck 2020-09-25 13:05 ` Dr. David Alan Gilbert 2020-09-25 13:05 ` [Virtio-fs] " Dr. David Alan Gilbert 2020-09-25 16:05 ` Christian Schoenebeck 2020-09-25 16:05 ` [Virtio-fs] " Christian Schoenebeck 2020-09-25 16:33 ` Christian Schoenebeck 2020-09-25 16:33 ` [Virtio-fs] " Christian Schoenebeck 2020-09-25 18:51 ` Dr. David Alan Gilbert 2020-09-25 18:51 ` [Virtio-fs] " Dr. David Alan Gilbert 2020-09-27 12:14 ` Christian Schoenebeck 2020-09-27 12:14 ` [Virtio-fs] " Christian Schoenebeck 2020-09-29 13:03 ` Vivek Goyal 2020-09-29 13:03 ` [Virtio-fs] " Vivek Goyal 2020-09-29 13:28 ` Christian Schoenebeck 2020-09-29 13:28 ` [Virtio-fs] " Christian Schoenebeck 2020-09-29 13:49 ` Vivek Goyal [this message] 2020-09-29 13:49 ` Vivek Goyal 2020-09-29 13:59 ` Christian Schoenebeck 2020-09-29 13:59 ` [Virtio-fs] " Christian Schoenebeck 2020-09-29 13:17 ` Vivek Goyal 2020-09-29 13:17 ` [Virtio-fs] " Vivek Goyal 2020-09-29 13:49 ` Miklos Szeredi 2020-09-29 13:49 ` Miklos Szeredi 2020-09-29 14:01 ` Vivek Goyal 2020-09-29 14:01 ` Vivek Goyal 2020-09-29 14:54 ` Miklos Szeredi 2020-09-29 14:54 ` Miklos Szeredi 2020-09-29 15:28 ` Vivek Goyal 2020-09-29 15:28 ` Vivek Goyal 2020-09-25 12:11 ` tools/virtiofs: Multi threading seems to hurt performance Dr. David Alan Gilbert 2020-09-25 12:11 ` [Virtio-fs] " Dr. David Alan Gilbert 2020-09-25 13:11 ` Vivek Goyal 2020-09-25 13:11 ` [Virtio-fs] " Vivek Goyal 2020-09-21 20:16 ` Vivek Goyal 2020-09-21 20:16 ` [Virtio-fs] " Vivek Goyal 2020-09-22 11:09 ` Dr. David Alan Gilbert 2020-09-22 11:09 ` [Virtio-fs] " Dr. David Alan Gilbert 2020-09-22 22:56 ` Vivek Goyal 2020-09-22 22:56 ` [Virtio-fs] " Vivek Goyal 2020-09-23 12:50 ` Chirantan Ekbote 2020-09-23 12:59 ` Vivek Goyal 2020-09-25 11:35 ` Dr. David Alan Gilbert
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=20200929134942.GC220516@redhat.com \ --to=vgoyal@redhat.com \ --cc=archana.m.shinde@intel.com \ --cc=cdupontd@redhat.com \ --cc=dgilbert@redhat.com \ --cc=jose.carlos.venegas.munoz@intel.com \ --cc=qemu-devel@nongnu.org \ --cc=qemu_oss@crudebyte.com \ --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: linkBe 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.