On Fri, Mar 24, 2017 at 8:54 PM, Stefan Hajnoczi <stefa...@gmail.com> wrote: > On Thu, Mar 23, 2017 at 4:22 PM, Ashijeet Acharya > <ashijeetacha...@gmail.com> wrote: >> On Thu, Mar 23, 2017 at 8:39 PM, Stefan Hajnoczi <stefa...@gmail.com> wrote: >>> On Tue, Mar 21, 2017 at 09:14:08AM +0000, Ashijeet Acharya wrote: >>>> On Tue, 21 Mar 2017 at 13:21, Stefan Hajnoczi <stefa...@gmail.com> wrote: >>>> >>>> > On Sat, Mar 11, 2017 at 11:54 AM, Ashijeet Acharya >>>> > <ashijeetacha...@gmail.com> wrote: >>>> > > This series optimizes the I/O performance of VMDK driver. >>>> > > >>>> > > Patch 1 makes the VMDK driver to allocate multiple clusters at once. >>>> > Earlier >>>> > > it used to allocate cluster by cluster which slowed down its >>>> > > performance >>>> > to a >>>> > > great extent. >>>> > > >>>> > > Patch 2 changes the metadata update code to update the L2 tables for >>>> > multiple >>>> > > clusters at once. >> >> These are the commands I ran to test the write requests: >> >> My test file "test1.vmdk" is a 1G empty vmdk image created by using >> 'qemu-img' tool. >> >> Before optimization: >> $ ./bin/qemu-io -f vmdk --cache writeback >> qemu-io> open -n -o driver=vmdk test1.vmdk >> qemu-io> aio_write 0 128M >> qemu-io> wrote 134217728/134217728 bytes at offset 0 >> 128 MiB, 1 ops; 0:00:16.46 (7.772 MiB/sec and 0.0607 ops/sec) >> >> After optimization: >> $ ./bin/qemu-io -f vmdk --cache writeback >> qemu-io> open -n -o driver=vmdk test1.vmdk >> qemu-io> aio_write 0 128M >> qemu-io> wrote 134217728/134217728 bytes at offset 0 >> 128 MiB, 1 ops; 0:00:08.19 (15.627 MiB/sec and 0.1221 ops/sec) >> >> Will these work? > > It is best to avoid --cache writeback in performance tests because > using the host page cache puts the performance at the mercy of the > kernel's page cache.
Okay, understood. > > I have run the following benchmark using "qemu-img bench": > > This patch series improves 128 KB sequential write performance to an > empty VMDK file by 29%. > > Benchmark command: ./qemu-img bench -w -c 1024 -s 128K -d 1 -t none -f > vmdk test.vmdk > > (Please include the 2 lines above in the next revision of the patch.) > Yes, I will do that. Also, this really helped me understand how to actually test I/O optimizations. Thanks for your help, this really solved my issue. Ashijeet