From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46029) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VC5ow-0000lA-63 for qemu-devel@nongnu.org; Wed, 21 Aug 2013 06:39:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VC5oq-0002r6-5h for qemu-devel@nongnu.org; Wed, 21 Aug 2013 06:39:22 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40508) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VC5op-0002qx-RV for qemu-devel@nongnu.org; Wed, 21 Aug 2013 06:39:16 -0400 Message-ID: <521498A1.8080500@redhat.com> Date: Wed, 21 Aug 2013 12:38:25 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1377023667-20256-1-git-send-email-charlie@ctshepherd.com> <5213D628.4030409@redhat.com> <5213F37C.8090300@ctshepherd.com> <521476ED.5030308@redhat.com> <52148453.8030109@ctshepherd.com> <5214861D.6090304@redhat.com> <521496E9.4010901@ctshepherd.com> In-Reply-To: <521496E9.4010901@ctshepherd.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/2] Make cow_co_is_allocated and cow_update_bitmap more efficient List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Charlie Shepherd Cc: kwolf@redhat.com, stefanha@gmail.com, gabriel@kerneis.info, qemu-devel@nongnu.org Il 21/08/2013 12:31, Charlie Shepherd ha scritto: > On 21/08/2013 10:19, Paolo Bonzini wrote: >> Il 21/08/2013 11:11, Charlie Shepherd ha scritto: >>> It still seems >>> worthwhile to me to be as efficient as possible, I guess that means >>> processing a sector's worth of metadata at a time? >> Yes, that's what my patches do. My is_allocated and flushing strategy + >> something like your replacement of cow_set_bit (just without the >> unbounded allocation) should be pretty good. >> >> Perhaps you can use a cow_co_is_allocated loop after writing the data. >> If it returns 0, you flush (the first time only) and call your >> cow_update_bitmap. Then you advance by num_same sectors and go on until >> you did all the nb_sectors. The disadvantage is that it does two reads >> (one in cow_co_is_allocated, one in cow_update_bitmap). The advantage >> is that unbounded allocation goes away because cow_co_is_allocated will >> never consider more than a sector of bitmap data. And you can reuse all >> your cow_update_bitmap code. > > Agreed. But can the two functions not share the same read data? Yes, of course! Good idea. Paolo