From: John Snow <jsnow@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@parallels.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: Tue, 10 Feb 2015 16:30:46 -0500 [thread overview]
Message-ID: <54DA7886.8060705@redhat.com> (raw)
In-Reply-To: <1422356197-5285-5-git-send-email-vsementsov@parallels.com>
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.
> 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.
next prev parent reply other threads:[~2015-02-10 21:30 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 [this message]
2015-02-12 10:51 ` Vladimir Sementsov-Ogievskiy
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=54DA7886.8060705@redhat.com \
--to=jsnow@redhat.com \
--cc=den@openvz.org \
--cc=kwolf@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
--cc=vsementsov@parallels.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.