From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44017) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a6dCV-0005Rk-AW for qemu-devel@nongnu.org; Wed, 09 Dec 2015 06:46:28 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a6dCS-0005L0-Je for qemu-devel@nongnu.org; Wed, 09 Dec 2015 06:46:27 -0500 Message-ID: <5668147C.5060702@virtuozzo.com> Date: Wed, 9 Dec 2015 14:46:04 +0300 From: Vladimir Sementsov-Ogievskiy MIME-Version: 1.0 References: <1449467995-18793-1-git-send-email-famz@redhat.com> <56659561.4070709@virtuozzo.com> <20151208014256.GD7567@ad.usersys.redhat.com> In-Reply-To: <20151208014256.GD7567@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 Cc: Kevin Wolf , qemu-block@nongnu.org, qemu-devel@nongnu.org, Stefan Hajnoczi , pbonzini@redhat.com, jsnow@redhat.com On 08.12.2015 04:42, Fam Zheng wrote: > On Mon, 12/07 17:19, Vladimir Sementsov-Ogievskiy wrote: >> On 07.12.2015 08:59, 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. >> What is the benefit? >> >> Hbitmap usage: >> >> 1) BdrvDirtyBitmap - need meta >> 2) BackupBlockJob - doesn't need meta >> 3) BlockDirtyBitmapState - doesn't need meta >> 4) now I'm working on series for parallels format and I use HBitmap >> to mark allocated/free clusters.. - doesn't need meta >> 5) your meta hbitmap =) - doesn't need meta.. > 6) persistence dirty bitmap. - need meta Your (6) is my (1) > >> So, what is the benefit of moving this functionality to parent >> class? (Which is complicated without it).. > See my reply to John's comment on the cover letter. This is more efficient than > doing it in BdrvDirtyBitmap. > >> However, I'm not really against, except my comment to the first patch. >> >> PS: >> Actually I don't like HBitmap - BdrvDirtyBitmap.. >> - No implementation without granularity >> I need HBitmap without granularity for my needs and have to >> use granularity=0. If there was HBitmap without granularity some >> operations can be faster - for example, finding next/previous/last >> zeros, jumping by words not by bits.. >> - It is not sparse. Empty bitmap occupies lots of ram. >> - different granularity units for HBitmap and BdrvDirtyBitmap >> - different layers with/without granularity in hbitmap.c >> - HBitmap with non-zero granularity doesn't know its size (only >> rounded up to granularity) >> - necessity of writing wrappers like >> bdrv_dirty_bitmap_do_something(...) >> { >> hbitmap_do_something(...) >> } >> -- Yes, I understand that this is inevitably, but I just don't like it.. >> - BdrvDirtyBitmap is defined in block.c.. I think, it should have >> its own .c file. > Yes, I agree we should cut it out during 2.6, with a separate header. > -- Best regards, Vladimir * now, @virtuozzo.com instead of @parallels.com. Sorry for this inconvenience.