qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/2] Allocate mutiple clusters for VMDK I/O


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [PATCH 0/2] Allocate mutiple clusters for VMDK I/O
Date: Thu, 23 Mar 2017 15:09:55 +0000
User-agent: Mutt/1.8.0 (2017-02-23)

On Tue, Mar 21, 2017 at 09:14:08AM +0000, Ashijeet Acharya wrote:
> On Tue, 21 Mar 2017 at 13:21, Stefan Hajnoczi <address@hidden> wrote:
> 
> > On Sat, Mar 11, 2017 at 11:54 AM, Ashijeet Acharya
> > <address@hidden> 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.
> >
> > This patch series is a performance optimization.  Benchmark results
> > are required to justify optimizations.  Please include performance
> > results in the next revision.
> >
> > A popular disk I/O benchmarking is fio (https://github.com/axboe/fio).
> > I suggest a write-heavy workload with a large block size:
> >
> > $ cat fio.job
> > [global]
> > direct=1
> > filename=/dev/vdb
> > ioengine=libaio
> > runtime=30
> > ramp_time=5
> >
> > [job1]
> > iodepth=4
> > rw=randwrite
> > bs=256k
> > $ for i in 1 2 3 4 5; do fio --output=fio-$i.txt fio.job; done #
> > WARNING: overwrites /dev/vdb
> >
> > It's good practice to run the benchmark several times because there is
> > usually some variation between runs.  This allows you to check that
> > the variance is within a reasonable range (5-10% on a normal machine
> > that hasn't been specially prepared for benchmarking).
> 
> 
> I ran a few write tests of 128M using qemu-io and the results showed the
> time to drop to almost half, will those work? Although, I will also try to
> use the tool you mentioned later today when I am free and include those
> results as well.

Maybe, it's hard to say without seeing the commands you ran.

Stefan

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]