From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47278) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XEGei-0002sc-A3 for qemu-devel@nongnu.org; Mon, 04 Aug 2014 07:42:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XEGea-0004lw-LQ for qemu-devel@nongnu.org; Mon, 04 Aug 2014 07:42:20 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:39579) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XEGea-0004lm-F4 for qemu-devel@nongnu.org; Mon, 04 Aug 2014 07:42:12 -0400 Received: from mail-vc0-f175.google.com ([209.85.220.175]) by youngberry.canonical.com with esmtpsa (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.71) (envelope-from ) id 1XEGeZ-0003zR-2N for qemu-devel@nongnu.org; Mon, 04 Aug 2014 11:42:11 +0000 Received: by mail-vc0-f175.google.com with SMTP id ik5so10596032vcb.6 for ; Mon, 04 Aug 2014 04:42:10 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <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> <20140804102138.GC5784@stefanha-thinkpad.redhat.com> Date: Mon, 4 Aug 2014 19:42:09 +0800 Message-ID: From: Ming Lei Content-Type: text/plain; charset=UTF-8 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: Stefan Hajnoczi Cc: Kevin Wolf , Peter Maydell , Fam Zheng , "Michael S. Tsirkin" , qemu-devel , Paolo Bonzini On Mon, Aug 4, 2014 at 6:21 PM, Stefan Hajnoczi wrote: > On Fri, Aug 01, 2014 at 03:42:05PM +0800, Ming Lei wrote: >> On Thu, Jul 31, 2014 at 5:18 PM, Paolo Bonzini wrote: >> > Il 31/07/2014 05:22, Ming Lei ha scritto: >> >>> > >> >>> > The problem is that g_slice here is not using the slab-style allocator >> >>> > because the object is larger than roughly 500 bytes. One solution would >> >>> > be to make virtqueue_pop/vring_pop allocate a VirtQueueElement of the >> >>> > 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 it'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. >> >> 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. The patch shouldn't be complicated too, and the only annoying part is to find each virtio device's load/save , and add the conversion in the two functions if VirtQueueElement is involved. I suggest to do the conversion in another standalone patchset. Thanks,