From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46321) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a6dNF-0001dt-Tb for qemu-devel@nongnu.org; Wed, 09 Dec 2015 06:57:34 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a6dNC-0008Dk-ME for qemu-devel@nongnu.org; Wed, 09 Dec 2015 06:57:33 -0500 Message-ID: <5668171E.4000709@virtuozzo.com> Date: Wed, 9 Dec 2015 14:57:18 +0300 From: Vladimir Sementsov-Ogievskiy MIME-Version: 1.0 References: <1449467995-18793-1-git-send-email-famz@redhat.com> <56661A7C.7020301@redhat.com> <20151208013628.GC7567@ad.usersys.redhat.com> In-Reply-To: <20151208013628.GC7567@ad.usersys.redhat.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH RFC for-2.6 0/3] block: Add meta dirty bitmap for migration/persistence List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fam Zheng , John Snow Cc: Kevin Wolf , pbonzini@redhat.com, Stefan Hajnoczi , qemu-devel@nongnu.org, qemu-block@nongnu.org On 08.12.2015 04:36, Fam Zheng wrote: > On Mon, 12/07 18:47, John Snow wrote: >> >> On 12/07/2015 12:59 AM, Fam Zheng wrote: >>> Vladimir, >>> >>> This is what I propose to implement meta bitmap. It's implemented in the >>> HBitmap level to be more efficient, and the interface slightly varies too. >>> >> I missed it: What was wrong with Vladimir's approach / what are the >> benefits of this approach? > The only real difference with this series is, only actual bit toggling will > mark meta dirty. Vladimir's approach was in BdrvDirtyBitmap level which can't > tell bit toggling from repetitive bit set/unset. This is from his patch: Ok, you are right. It's truth. > > @@ -3390,6 +3428,9 @@ void bdrv_set_dirty_bitmap(BdrvDirtyBitmap *bitmap, > { > assert(bdrv_dirty_bitmap_enabled(bitmap)); > hbitmap_set(bitmap->bitmap, cur_sector, nr_sectors); > + if (bitmap->meta_bitmap) { > + hbitmap_set(bitmap->meta_bitmap, cur_sector, nr_sectors); > + } > } > > void bdrv_reset_dirty_bitmap(BdrvDirtyBitmap *bitmap, > @@ -3397,6 +3438,9 @@ void bdrv_reset_dirty_bitmap(BdrvDirtyBitmap *bitmap, > { > assert(bdrv_dirty_bitmap_enabled(bitmap)); > hbitmap_reset(bitmap->bitmap, cur_sector, nr_sectors); > + if (bitmap->meta_bitmap) { > + hbitmap_set(bitmap->meta_bitmap, cur_sector, nr_sectors); > + } > } > > void bdrv_clear_dirty_bitmap(BdrvDirtyBitmap *bitmap) > >>> I'd like to use these operations to make dirty bitmap persistence more >>> efficient too: unchanged dirty bits don't need to be flushed to disk. So I'm >>> posting this as a separate series for a common base for both sides. >>> >> This is a reasonable use of the meta-bitmap strategy in general. >> >> Keep in mind Vladimir's approach to Meta bitmaps used a different >> granularity such that 1 physical bit implied 1 sector needed to be >> re-transmitted. > Yes, I can fix the meta bitmap granularity. > >> A meta-bitmap that keeps track of disk flushes may require a different >> granularity than one used for migration. >> >>> Posting as RFC as 2.6 dev phase is just starting, we can still tweak the >>> interface and/or implementation to fit the need. >>> >>> Fam Zheng (3): >>> HBitmap: Introduce "meta" bitmap to track bit changes >>> tests: Add test code for meta bitmap >>> block: Support meta dirty bitmap >>> >>> block.c | 46 ++++++++++++++++++++++++++++++- >>> block/mirror.c | 3 +- >>> blockdev.c | 3 +- >>> include/block/block.h | 11 ++++++++ >>> include/qemu/hbitmap.h | 7 +++++ >>> migration/block.c | 2 +- >>> tests/test-hbitmap.c | 74 ++++++++++++++++++++++++++++++++++++++++++++++++++ >>> util/hbitmap.c | 22 +++++++++++++++ >>> 8 files changed, 164 insertions(+), 4 deletions(-) >>> -- Best regards, Vladimir * now, @virtuozzo.com instead of @parallels.com. Sorry for this inconvenience.