From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58106) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XPqMF-0005jM-IB for qemu-devel@nongnu.org; Fri, 05 Sep 2014 06:03:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XPqM5-0001YW-Kh for qemu-devel@nongnu.org; Fri, 05 Sep 2014 06:03:07 -0400 Received: from mail-wg0-x22b.google.com ([2a00:1450:400c:c00::22b]:50165) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XPqM5-0001Y1-Dt for qemu-devel@nongnu.org; Fri, 05 Sep 2014 06:02:57 -0400 Received: by mail-wg0-f43.google.com with SMTP id a1so11255231wgh.2 for ; Fri, 05 Sep 2014 03:02:56 -0700 (PDT) Date: Fri, 5 Sep 2014 11:02:51 +0100 From: Stefan Hajnoczi Message-ID: <20140905100251.GD18562@stefanha-thinkpad.redhat.com> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uxuisgdDHaNETlh8" Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] I/O parallelism on QCOW2 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Xingbo Wu Cc: qemu-devel@nongnu.org --uxuisgdDHaNETlh8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 --uxuisgdDHaNETlh8 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUCYpLAAoJEJykq7OBq3PI3kgIAK1iDHyo76QuL6iDPELUthAX 7i34ao+aW/CojrxCIKQbNCxRNu7vt/Acid/sy7s6B71/s+Vi5RroOpfGTB3hwPQA C37vEkkha1eVp+pMG78nHw9ea1tV2VZf6GdjHVT59Suwhn1Csq29mAA0Atz6U8K+ AUKP+YwVirJulNr1uN6JtSe0PxbDQOFIMygowyF19KYQIx4tcOspvbmNkXl5/tM/ 1qoiwxBsfxVlZuzuiJ67oTWKj0NRxFeZK2qShYOmIJV5oEGHhdrflgu4btwyDVWS xQX2kYjZQncbAAf2bCQcG5wslGc3xVgPwyHsPoRHIItlEo1sqvM1C3IYsBcIWL8= =FdzQ -----END PGP SIGNATURE----- --uxuisgdDHaNETlh8--