[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] I/O parallelism on QCOW2
From: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-devel] I/O parallelism on QCOW2 |
Date: |
Fri, 5 Sep 2014 11:02:51 +0100 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
On Thu, Sep 04, 2014 at 12:32:12PM -0400, Xingbo Wu wrote:
> After running a 16-thread sync-random-write test against qcow2, It is
> observed that QCOW2 seems to be serializing all its metadata-related writes.
> If qcow2 is designed to do this,* then what is the concern?* What would go
> wrong if this ordering is relaxed?
How do you know that serializing part of the write request is a
significant bottleneck?
Please post your benchmark results with raw, qed, and qcow2 handling 1-,
8-, and 16-threads of I/O (or whatever similar benchmarks you have run).
The bottleneck may actually be something else, so please share your
benchmark configuration and results.
> By providing less features, raw-file and QED scales well on parallel I/O
> workload. I believe qcow2 does this with clear reasons. Thanks!
QED serializes allocating writes, see qed_aio_write_alloc().
In qcow2 the BdrvQcowState->lock is held across metadata updates. The
important pieces here are:
* qcow2_co_writev() only releases the lock around data writes
(including COW).
* qcow2_co_flush_to_os() holds the lock around metadata updates
Stefan
pgp9gFsHb0JAw.pgp
Description: PGP signature