From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60859) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XEFOo-00028U-U3 for qemu-devel@nongnu.org; Mon, 04 Aug 2014 06:21:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XEFOi-00039N-O6 for qemu-devel@nongnu.org; Mon, 04 Aug 2014 06:21:50 -0400 Received: from mx1.redhat.com ([209.132.183.28]:20087) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XEFOi-00039F-HR for qemu-devel@nongnu.org; Mon, 04 Aug 2014 06:21:44 -0400 Date: Mon, 4 Aug 2014 11:21:38 +0100 From: Stefan Hajnoczi Message-ID: <20140804102138.GC5784@stefanha-thinkpad.redhat.com> References: <1406720388-18671-1-git-send-email-ming.lei@canonical.com> <1406720388-18671-8-git-send-email-ming.lei@canonical.com> <53D8FDB1.2060603@redhat.com> <53DA09CA.20604@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vOmOzSkFvhd7u8Ms" Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH 07/15] dataplane: use object pool to speed up allocation for virtio blk request List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ming Lei Cc: Kevin Wolf , Peter Maydell , Fam Zheng , "Michael S. Tsirkin" , qemu-devel , Paolo Bonzini --vOmOzSkFvhd7u8Ms Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 01, 2014 at 03:42:05PM +0800, Ming Lei wrote: > On Thu, Jul 31, 2014 at 5:18 PM, Paolo Bonzini wrot= e: > > Il 31/07/2014 05:22, Ming Lei ha scritto: > >>> > > >>> > The problem is that g_slice here is not using the slab-style alloca= tor > >>> > because the object is larger than roughly 500 bytes. One solution = would > >>> > be to make virtqueue_pop/vring_pop allocate a VirtQueueElement of t= he > >>> > right size (and virtqueue_push/vring_push free it), as mentioned in= the > >>> > review of patch 8. > >> Unluckily both iovec and addr array can't be fitted into 500 bytes, :-( > >> Not mention all users of VirtQueueElement need to be changed too, > >> I hate to make that work involved in this patchset, :-) > > > > Well, the point of dataplane was not just to get maximum iops. It was > > also to provide guidance in the work necessary to improve the code and > > get maximum iops without special-casing everything. This can be a lot > > of work indeed. > > > >>> > > >>> > However, I now remembered that VirtQueueElement is a mess because i= t's > >>> > serialized directly into the migration state. :( So you basically > >>> > cannot change it without mucking with migration. Please leave out = patch > >>> > 8 for now. > >> save_device code serializes elem in this way: > >> > >> qemu_put_buffer(f, (unsigned char *)&req->elem, > >> sizeof(VirtQueueElement)); > >> > >> so I am wondering why this patch may break migration. > > > > Because you change the on-wire format and break migration from 2.1 to > > 2.2. Sorry, I wasn't clear enough. >=20 > That is really a mess, but in future we still may convert VirtQueueElement > into a smart one, and keep the original structure only for save/load, but > a conversion between the two structures is required in save/load. This is a good idea. The VirtQueueElement structure isn't complicated, it's just big. Just use the current layout as the serialization format. Stefan --vOmOzSkFvhd7u8Ms Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJT316yAAoJEJykq7OBq3PICc4H/Ap7Xaziq5p0TeIJbIZEcP4C 1D10VoROp1An4k+vUSuM8BAd1kbnNmLKxJA5UhwRy+oB+hVw4UENpXVCn2qIeH0P bn+s3PZx5goWaRJFuoxXHCCZX1UM96uUEZCAYM5eBmYlBtIfVIwtHv2Uf8xYR0+E VQXGmwzU2uxsBdhsbO8VVPEUunHwvNwUQNhykyfUyNcLX5dNILvl18lttQorzEt/ NQB+jBRcLVGEdiLU+ee+yXU64FqFz8+elhj12BpPeKrNMQJdodMtWCES2uM39zZV yr1cEN5VpsNqilkCpUrWx40niNTiaWQfrh9NTXhswfgpyxgt+r7LYseXILCIc3U= =fsQh -----END PGP SIGNATURE----- --vOmOzSkFvhd7u8Ms--