qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Hyman Huang <yong.huang@smartx.com>, qemu-devel@nongnu.org
Cc: Peter Xu <peterx@redhat.com>, Fabiano Rosas <farosas@suse.de>,
	Wei Wang <wei.w.wang@intel.com>,
	"Michael S . Tsirkin" <mst@redhat.com>
Subject: Re: [PATCH v1 2/2] migration: Do not perform RAMBlock dirty sync during the first iteration
Date: Mon, 11 Nov 2024 10:27:01 +0100	[thread overview]
Message-ID: <b2e42ed6-d514-46c9-993c-e7ae6384592f@redhat.com> (raw)
In-Reply-To: <c25abae360ac204321acc5010a745a8e594f24bd.1731128180.git.yong.huang@smartx.com>

On 09.11.24 05:59, Hyman Huang wrote:
> The first iteration's RAMBlock dirty sync can be omitted because QEMU
> always initializes the RAMBlock's bmap to all 1s by default.
> 
> Signed-off-by: Hyman Huang <yong.huang@smartx.com>
> ---
>   migration/cpu-throttle.c |  2 +-
>   migration/ram.c          | 11 ++++++++---
>   2 files changed, 9 insertions(+), 4 deletions(-)
> 
> diff --git a/migration/cpu-throttle.c b/migration/cpu-throttle.c
> index 5179019e33..674dc2004e 100644
> --- a/migration/cpu-throttle.c
> +++ b/migration/cpu-throttle.c
> @@ -141,7 +141,7 @@ void cpu_throttle_dirty_sync_timer_tick(void *opaque)
>        * effect on guest performance, therefore omit it to avoid
>        * paying extra for the sync penalty.
>        */
> -    if (sync_cnt <= 1) {
> +    if (!sync_cnt) {
>           goto end;
>       }
>   
> diff --git a/migration/ram.c b/migration/ram.c
> index 05ff9eb328..571dba10b7 100644
> --- a/migration/ram.c
> +++ b/migration/ram.c
> @@ -2718,7 +2718,7 @@ static void ram_list_init_bitmaps(void)
>   {
>       MigrationState *ms = migrate_get_current();
>       RAMBlock *block;
> -    unsigned long pages;
> +    unsigned long pages, clear_bmap_pages;
>       uint8_t shift;
>   
>       /* Skip setting bitmap if there is no RAM */
> @@ -2736,6 +2736,7 @@ static void ram_list_init_bitmaps(void)
>   
>           RAMBLOCK_FOREACH_NOT_IGNORED(block) {
>               pages = block->max_length >> TARGET_PAGE_BITS;
> +            clear_bmap_pages = clear_bmap_size(pages, shift);
>               /*
>                * The initial dirty bitmap for migration must be set with all
>                * ones to make sure we'll migrate every guest RAM page to
> @@ -2751,7 +2752,12 @@ static void ram_list_init_bitmaps(void)
>                   block->file_bmap = bitmap_new(pages);
>               }
>               block->clear_bmap_shift = shift;
> -            block->clear_bmap = bitmap_new(clear_bmap_size(pages, shift));
> +            block->clear_bmap = bitmap_new(clear_bmap_pages);
> +            /*
> +             * Set clear_bmap to 1 unconditionally, as we always set bmap
> +             * to all 1s by default.
> +             */
> +            bitmap_set(block->clear_bmap, 0, clear_bmap_pages);
>           }
>       }
>   }
> @@ -2783,7 +2789,6 @@ static bool ram_init_bitmaps(RAMState *rs, Error **errp)
>               if (!ret) {
>                   goto out_unlock;
>               }
> -            migration_bitmap_sync_precopy(false);
>           }
>       }
>   out_unlock:


For virtio-mem, we rely on the migration_bitmap_clear_discarded_pages() 
call to clear all bits that correspond to unplugged memory ranges.

If we ommit the sync, we can likely have bits of unplugged ranges still 
set to "1", meaning we would try migrate them later, although we shouldn't?

Or is that handled differently?

-- 
Cheers,

David / dhildenb



  parent reply	other threads:[~2024-11-11  9:32 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-09  4:59 [PATCH v1 0/2] migration: Skip the first dirty sync Hyman Huang
2024-11-09  4:59 ` [PATCH v1 1/2] virtio-balloon: Enable free page hinting during PRECOPY_NOTIFY_SETUP Hyman Huang
2024-11-12 10:10   ` David Hildenbrand
2024-11-09  4:59 ` [PATCH v1 2/2] migration: Do not perform RAMBlock dirty sync during the first iteration Hyman Huang
2024-11-11  9:07   ` Wang, Wei W
2024-11-11 10:20     ` Yong Huang
2024-11-11  9:27   ` David Hildenbrand [this message]
2024-11-11 10:08     ` Yong Huang
2024-11-11 10:42       ` David Hildenbrand
2024-11-11 11:14         ` Yong Huang
2024-11-11 11:37         ` Yong Huang
2024-11-12 10:08           ` David Hildenbrand
2024-11-13 17:40             ` Peter Xu
2024-11-13 18:49               ` David Hildenbrand
2024-11-13 20:12                 ` Peter Xu
2024-11-14  9:02                   ` David Hildenbrand
2024-11-14 19:28                     ` Peter Xu
2024-11-14 21:16                       ` David Hildenbrand
2024-11-14 22:40                         ` Peter Xu
2024-11-15  9:11                           ` David Hildenbrand
2024-11-15 15:41                             ` Peter Xu
2024-11-15 15:49                               ` David Hildenbrand

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=b2e42ed6-d514-46c9-993c-e7ae6384592f@redhat.com \
    --to=david@redhat.com \
    --cc=farosas@suse.de \
    --cc=mst@redhat.com \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=wei.w.wang@intel.com \
    --cc=yong.huang@smartx.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).