From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36236) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XHrVN-0005PT-EV for qemu-devel@nongnu.org; Thu, 14 Aug 2014 05:39:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XHrVH-0000A2-9d for qemu-devel@nongnu.org; Thu, 14 Aug 2014 05:39:33 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45270) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XHrVH-00009f-1x for qemu-devel@nongnu.org; Thu, 14 Aug 2014 05:39:27 -0400 Date: Thu, 14 Aug 2014 10:39:21 +0100 From: Stefan Hajnoczi Message-ID: <20140814093921.GD9874@stefanha-thinkpad.redhat.com> References: <20140805144728.GH4391@noname.str.redhat.com> <20140806084855.GA4090@noname.str.redhat.com> <20140810114624.0305b7af@tom-ThinkPad-T410> <53E91B5D.4090009@redhat.com> <53EA6635.9040600@redhat.com> <20140813095400.GA3701@noname.redhat.com> <53EB654B.2020200@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LKTjZJSUETSlgu2t" Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH v1 00/17] dataplane: optimization and multi virtqueue support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ming Lei Cc: Kevin Wolf , Paolo Bonzini , Fam Zheng , qemu-devel --LKTjZJSUETSlgu2t Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 13, 2014 at 09:49:23PM +0800, Ming Lei wrote: > On Wed, Aug 13, 2014 at 9:16 PM, Paolo Bonzini wrot= e: > > Il 13/08/2014 11:54, Kevin Wolf ha scritto: > >> Am 12.08.2014 um 21:08 hat Paolo Bonzini geschrieben: > >>> Il 12/08/2014 10:12, Ming Lei ha scritto: > >>>>>> The below patch is basically the minimal change to bypass coroutin= es. Of course > >>>>>> the block.c part is not acceptable as is (the change to refresh_to= tal_sectors > >>>>>> is broken, the others are just ugly), but it is a start. Please r= un it with > >>>>>> your fio workloads, or write an aio-based version of a qemu-img/qe= mu-io *I/O* > >>>>>> benchmark. > >>>> Could you explain why the new change is introduced? > >>> > >>> It provides a fast path for bdrv_aio_readv/writev whenever there is > >>> nothing to do after the driver routine returns. In this case there is > >>> no need to wrap the AIOCB returned by the driver routine. > >>> > >>> It doesn't go all the way, and in particular it doesn't reverse > >>> completely the roles of bdrv_co_readv/writev vs. bdrv_aio_readv/write= v. > >> > >> That's actually why I think it's an option. Remember that, like you say > >> below, we're optimising for an extreme case here, and I certainly don't > >> want to hurt the common case for it. I can't imagine a way of reversing > >> the roles without multiplying the cost for the coroutine path. > > > > I'm not that worried about it. Perhaps it's enough to add an > > !qemu_in_coroutine() to the AIO fast path, and let the driver provide > > optimized coroutine paths like in your patches that allocate AIOCBs on > > the stack. >=20 > IMO, it will not be a extreme case as SSD or high performance storage > becomes more popular, coroutine starts to affect performance if IOPS > is more than 100K, as previous computation. The case you seem to care about is raw images on high IOPS devices. You mentioned 1M IOPS devices in another email. You don't seem to want QEMU's block layer features, that is why you are trying to bypass them instead of optimizing the block layer. That begs the question whether you should look at PCI passthrough instead? Stefan --LKTjZJSUETSlgu2t Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJT7IPJAAoJEJykq7OBq3PInJQH/0+wN6NFSz5SzFBFbNft91vJ pdjO04tPe3PtP7rQjiqsCwoqd+F3lYbEtgd1R5vhmlKQwTS+2zP2s2bm/6dCnqCe lQhSYIdMu0Z0xC6Oyg4QPlryqjIAUGPui382v+wSrSEhhqM8yxHIF4wuBdoaZali MQIDIgwZ6Ty4r1P3Bk02gBEurgQ88hLiIWX7EXzcMyoAke/6dQngR1jNnBM5IhEM jE9tPwfS71ZOg8Hg6vZc4abjS9dC3xdWnhEPt76hc9LOCo1ji2UlyDzruohsUBHq HbKmFSzevLuia5b/r2gfH5Dbe3MbyXP742oXh0lqOJxT1zNFBCrJsJj5QiFMi+A= =qSUW -----END PGP SIGNATURE----- --LKTjZJSUETSlgu2t--