From: Vladimir Sementsov-Ogievskiy <vsementsov@parallels.com>
To: John Snow <jsnow@redhat.com>, qemu-devel@nongnu.org
Cc: kwolf@redhat.com, pbonzini@redhat.com, stefanha@redhat.com,
den@openvz.org
Subject: Re: [Qemu-devel] [PATCH RFC v2 4/8] block: add dirty-dirty bitmaps
Date: Thu, 12 Feb 2015 13:51:45 +0300 [thread overview]
Message-ID: <54DC85C1.3040205@parallels.com> (raw)
In-Reply-To: <54DA7886.8060705@redhat.com>
On 11.02.2015 00:30, John Snow wrote:
> I had hoped it wouldn't come to this :)
>
> On 01/27/2015 05:56 AM, Vladimir Sementsov-Ogievskiy wrote:
>> A dirty-dirty bitmap is a dirty bitmap for BdrvDirtyBitmap. It tracks
>> set/unset changes of BdrvDirtyBitmap.
>>
>> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@parallels.com>
>> ---
>> block.c | 44
>> ++++++++++++++++++++++++++++++++++++++++++++
>> include/block/block.h | 5 +++++
>> 2 files changed, 49 insertions(+)
>>
>> diff --git a/block.c b/block.c
>> index 9860fc1..8ab724b 100644
>> --- a/block.c
>> +++ b/block.c
>> @@ -53,6 +53,7 @@
>>
>> struct BdrvDirtyBitmap {
>> HBitmap *bitmap;
>> + HBitmap *dirty_dirty_bitmap;
>
> Just opinions: Maybe we can call it the "meta_bitmap" to help keep the
> name less confusing, and accompany it with a good structure comment
> here to explain what the heck it's for.
>
> If you feel that's a good idea; s/dirty_dirty_/meta_/g below.
>
> Regardless, let's make sure this patch adds documentation for it.
No objections. If everyone is happy with meta_bitmaps - I'll use this
name. Dirty-dirty bitmaps are just more fanny, I think ;)
>
>> BdrvDirtyBitmap *originator;
>> int64_t size;
>> int64_t granularity;
>> @@ -5373,6 +5374,30 @@ BdrvDirtyBitmap
>> *bdrv_reclaim_dirty_bitmap(BlockDriverState *bs,
>> return originator;
>> }
>>
>> +HBitmap *bdrv_create_dirty_dirty_bitmap(BdrvDirtyBitmap *bitmap,
>> + uint64_t granularity)
>> +{
>> + uint64_t sector_granularity;
>> +
>> + assert((granularity & (granularity - 1)) == 0);
>> +
>> + granularity *= 8 * bitmap->granularity;
>> + sector_granularity = granularity >> BDRV_SECTOR_BITS;
>> + assert(sector_granularity);
>> +
>> + bitmap->dirty_dirty_bitmap =
>> + hbitmap_alloc(bitmap->size, ffsll(sector_granularity) - 1);
>> +
>> + return bitmap->dirty_dirty_bitmap;
>> +}
>> +
>> +void bdrv_release_dirty_dirty_bitmap(BdrvDirtyBitmap *bitmap)
>> +{
>> + if (bitmap->dirty_dirty_bitmap) {
>> + hbitmap_free(bitmap->dirty_dirty_bitmap);
>> + bitmap->dirty_dirty_bitmap = NULL;
>> + }
>> +}
>>
>> void bdrv_print_dirty_bitmap(BdrvDirtyBitmap *bitmap)
>> {
>> @@ -5447,6 +5472,9 @@ void bdrv_release_dirty_bitmap(BlockDriverState
>> *bs, BdrvDirtyBitmap *bitmap)
>> if (bm == bitmap) {
>> QLIST_REMOVE(bitmap, list);
>> hbitmap_free(bitmap->bitmap);
>> + if (bitmap->dirty_dirty_bitmap) {
>> + hbitmap_free(bitmap->dirty_dirty_bitmap);
>> + }
>> g_free(bitmap->name);
>> g_free(bitmap);
>> return;
>> @@ -5534,6 +5562,10 @@ void bdrv_set_dirty_bitmap(BlockDriverState
>> *bs, BdrvDirtyBitmap *bitmap,
>> {
>> if (bitmap->enabled) {
>> hbitmap_set(bitmap->bitmap, cur_sector, nr_sectors);
>> +
>> + if (bitmap->dirty_dirty_bitmap) {
>> + hbitmap_set(bitmap->dirty_dirty_bitmap, cur_sector,
>> nr_sectors);
>> + }
>> }
>> }
>>
>> @@ -5541,6 +5573,9 @@ void bdrv_reset_dirty_bitmap(BlockDriverState
>> *bs, BdrvDirtyBitmap *bitmap,
>> int64_t cur_sector, int nr_sectors)
>> {
>> hbitmap_reset(bitmap->bitmap, cur_sector, nr_sectors);
>> + if (bitmap->dirty_dirty_bitmap) {
>> + hbitmap_set(bitmap->dirty_dirty_bitmap, cur_sector,
>> nr_sectors);
>> + }
>> }
>>
>> /**
>> @@ -5550,6 +5585,9 @@ void bdrv_reset_dirty_bitmap(BlockDriverState
>> *bs, BdrvDirtyBitmap *bitmap,
>> void bdrv_clear_dirty_bitmap(BlockDriverState *bs, BdrvDirtyBitmap
>> *bitmap)
>> {
>> hbitmap_reset(bitmap->bitmap, 0, bitmap->size);
>> + if (bitmap->dirty_dirty_bitmap) {
>> + hbitmap_set(bitmap->dirty_dirty_bitmap, 0, bitmap->size);
>> + }
>> }
>>
>> const char *bdrv_dirty_bitmap_name(const BdrvDirtyBitmap *bitmap)
>> @@ -5597,6 +5635,9 @@ static void bdrv_set_dirty(BlockDriverState
>> *bs, int64_t cur_sector,
>> continue;
>> }
>> hbitmap_set(bitmap->bitmap, cur_sector, nr_sectors);
>> + if (bitmap->dirty_dirty_bitmap) {
>> + hbitmap_set(bitmap->dirty_dirty_bitmap, cur_sector,
>> nr_sectors);
>> + }
>> }
>> }
>>
>> @@ -5606,6 +5647,9 @@ static void bdrv_reset_dirty(BlockDriverState
>> *bs, int64_t cur_sector,
>> BdrvDirtyBitmap *bitmap;
>> QLIST_FOREACH(bitmap, &bs->dirty_bitmaps, list) {
>> hbitmap_reset(bitmap->bitmap, cur_sector, nr_sectors);
>> + if (bitmap->dirty_dirty_bitmap) {
>> + hbitmap_set(bitmap->dirty_dirty_bitmap, cur_sector,
>> nr_sectors);
>> + }
>> }
>> }
>>
>> diff --git a/include/block/block.h b/include/block/block.h
>> index 0890cd2..648b0a9 100644
>> --- a/include/block/block.h
>> +++ b/include/block/block.h
>> @@ -4,6 +4,7 @@
>> #include "block/aio.h"
>> #include "qemu-common.h"
>> #include "qemu/option.h"
>> +#include "qemu/hbitmap.h"
>> #include "block/coroutine.h"
>> #include "block/accounting.h"
>> #include "qapi/qmp/qobject.h"
>> @@ -473,6 +474,10 @@ void
>> bdrv_dirty_bitmap_deserialize_part0(BdrvDirtyBitmap *bitmap,
>> uint64_t start, uint64_t
>> count);
>> void bdrv_dirty_bitmap_deserialize_finish(BdrvDirtyBitmap *bitmap);
>>
>> +HBitmap *bdrv_create_dirty_dirty_bitmap(BdrvDirtyBitmap *bitmap,
>> + uint64_t granularity);
>> +void bdrv_release_dirty_dirty_bitmap(BdrvDirtyBitmap *bitmap);
>> +
>> void bdrv_enable_copy_on_read(BlockDriverState *bs);
>> void bdrv_disable_copy_on_read(BlockDriverState *bs);
>>
>>
>
> Looks correct, it just needs documentation in my opinion to help
> explain what this extra bitmap is for.
>
> Musings / opinions:
>
> I also think that at this point, we may want to make bdrv_reset_dirty
> and bdrv_set_dirty call the bdrv_reset_dirty_bitmap and
> bdrv_set_dirty_bitmap functions instead of re-implementing the behavior.
>
> I used to think it was fine as-is, but the more conditions we add to
> how these bitmaps should be accessed, the more I think limiting the
> interface to as few functions as possible is a good idea.
>
> Maybe I'll even do that myself. It might even be nice to split off all
> the bitmap functions off into something like block/dirty_bitmaps.c as
> the complexity creeps up and we're trying to improve the
> maintainability of block.c.
>
> Anyway, we can worry about that in a later series.
--
Best regards,
Vladimir
next prev parent reply other threads:[~2015-02-12 11:03 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-27 10:56 [Qemu-devel] [PATCH RFC v2 0/8] Dirty bitmaps migration Vladimir Sementsov-Ogievskiy
2015-01-27 10:56 ` [Qemu-devel] [PATCH RFC v2 1/8] qmp: print dirty bitmap Vladimir Sementsov-Ogievskiy
2015-01-27 16:17 ` Eric Blake
2015-01-27 16:23 ` Vladimir Sementsov-Ogievskiy
2015-02-10 21:28 ` John Snow
2015-01-27 10:56 ` [Qemu-devel] [PATCH RFC v2 2/8] hbitmap: serialization Vladimir Sementsov-Ogievskiy
2015-02-10 21:29 ` John Snow
2015-01-27 10:56 ` [Qemu-devel] [PATCH RFC v2 3/8] block: BdrvDirtyBitmap serialization interface Vladimir Sementsov-Ogievskiy
2015-02-10 21:29 ` John Snow
2015-01-27 10:56 ` [Qemu-devel] [PATCH RFC v2 4/8] block: add dirty-dirty bitmaps Vladimir Sementsov-Ogievskiy
2015-02-10 21:30 ` John Snow
2015-02-12 10:51 ` Vladimir Sementsov-Ogievskiy [this message]
2015-01-27 10:56 ` [Qemu-devel] [PATCH RFC v2 5/8] block: add bdrv_dirty_bitmap_enabled() Vladimir Sementsov-Ogievskiy
2015-02-10 21:30 ` John Snow
2015-02-12 10:54 ` Vladimir Sementsov-Ogievskiy
2015-02-12 16:22 ` John Snow
2015-01-27 10:56 ` [Qemu-devel] [PATCH RFC v2 6/8] block: add bdrv_next_dirty_bitmap() Vladimir Sementsov-Ogievskiy
2015-02-10 21:31 ` John Snow
2015-01-27 10:56 ` [Qemu-devel] [PATCH RFC v2 7/8] migration: add dirty parameter Vladimir Sementsov-Ogievskiy
2015-01-27 16:20 ` Eric Blake
2015-02-04 14:42 ` Vladimir Sementsov-Ogievskiy
2015-02-10 21:32 ` John Snow
2015-01-27 10:56 ` [Qemu-devel] [PATCH RFC v2 8/8] migration: add migration/dirty-bitmap.c Vladimir Sementsov-Ogievskiy
2015-02-10 21:33 ` John Snow
2015-02-13 8:19 ` Vladimir Sementsov-Ogievskiy
2015-02-13 9:06 ` Vladimir Sementsov-Ogievskiy
2015-02-13 17:32 ` John Snow
2015-02-13 17:41 ` Vladimir Sementsov-Ogievskiy
2015-02-13 20:22 ` John Snow
2015-02-16 12:06 ` Vladimir Sementsov-Ogievskiy
2015-02-16 18:18 ` John Snow
2015-02-16 18:22 ` Dr. David Alan Gilbert
2015-02-17 8:54 ` Vladimir Sementsov-Ogievskiy
2015-02-17 18:45 ` John Snow
2015-02-17 19:12 ` Eric Blake
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54DC85C1.3040205@parallels.com \
--to=vsementsov@parallels.com \
--cc=den@openvz.org \
--cc=jsnow@redhat.com \
--cc=kwolf@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.