From: Peter Xu <peterx@redhat.com>
To: Yong Huang <yong.huang@smartx.com>
Cc: "Fabiano Rosas" <farosas@suse.de>,
qemu-devel@nongnu.org, "Eric Blake" <eblake@redhat.com>,
"Markus Armbruster" <armbru@redhat.com>,
"David Hildenbrand" <david@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Paolo Bonzini" <pbonzini@redhat.com>
Subject: Re: [PATCH v1 1/7] migration: Introduce structs for background sync
Date: Thu, 26 Sep 2024 15:55:27 -0400 [thread overview]
Message-ID: <ZvW8LxJsv3pRWom_@x1n> (raw)
In-Reply-To: <CAK9dgmbi1VSXvxFjziH5PjaoiaQwBJ3z4ff1BAojtm26VTThUQ@mail.gmail.com>
On Fri, Sep 27, 2024 at 02:13:47AM +0800, Yong Huang wrote:
> On Thu, Sep 26, 2024 at 3:17 AM Peter Xu <peterx@redhat.com> wrote:
>
> > On Fri, Sep 20, 2024 at 10:43:31AM +0800, Yong Huang wrote:
> > > Yes, invoke migration_bitmap_sync_precopy more frequently is also my
> > > first idea but it involves bitmap updating and interfere with the
> > behavior
> > > of page sending, it also affects the migration information stats and
> > > interfere other migration logic such as migration_update_rates().
> >
> > Could you elaborate?
> >
> > For example, what happens if we start to sync in ram_save_iterate() for
> > some time intervals (e.g. 5 seconds)?
> >
>
> I didn't try to sync in ram_save_iterate but in the
> migration_bitmap_sync_precopy.
>
> If we use the migration_bitmap_sync_precopy in the ram_save_iterate
> function,
> This approach seems to be correct. However, the bitmap will be updated as
> the
> migration thread iterates through each dirty page in the RAMBlock list.
> Compared
> to the existing implementation, this is different but still straightforward;
> I'll give it a shot soon to see if it works.
It's still serialized in the migration thread, so I'd expect it is similar
to e.g. ->state_pending_exact() calls when QEMU flushed most dirty pages in
the current bitmap.
>
>
> > Btw, we shouldn't have this extra sync exist if auto converge is disabled
> > no matter which way we use, because it's pure overhead when auto converge
> > is not in use.
> >
>
> Ok, I'll add the check in the next versioni.
Let's start with simple, and if there's anything unsure we can discuss
upfront, just to avoid coding something and change direction later. Again,
personally I think we shouldn't add too much new code to auto converge
(unless very well justfied, but I think it's just hard.. fundamentally with
any pure throttling solutions), hopefully something small can make it start
to work for huge VMs.
Thanks,
--
Peter Xu
next prev parent reply other threads:[~2024-09-26 19:56 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-15 16:08 [PATCH v1 0/7] migration: auto-converge refinements for huge VM Hyman Huang
2024-09-15 16:08 ` [PATCH v1 1/7] migration: Introduce structs for background sync Hyman Huang
2024-09-16 21:11 ` Fabiano Rosas
2024-09-17 6:48 ` Yong Huang
2024-09-19 18:45 ` Peter Xu
2024-09-20 2:43 ` Yong Huang
2024-09-25 19:17 ` Peter Xu
2024-09-26 18:13 ` Yong Huang
2024-09-26 19:55 ` Peter Xu [this message]
2024-09-27 2:50 ` Yong Huang
2024-09-27 15:35 ` Peter Xu
2024-09-27 16:44 ` Hyman Huang
2024-09-28 5:07 ` Yong Huang
2024-09-20 3:02 ` Yong Huang
2024-09-20 3:13 ` Yong Huang
2024-09-15 16:08 ` [PATCH v1 2/7] migration: Refine util functions to support " Hyman Huang
2024-09-15 16:08 ` [PATCH v1 3/7] qapi/migration: Introduce the iteration-count Hyman Huang
2024-09-16 20:35 ` Fabiano Rosas
2024-09-17 6:52 ` Yong Huang
2024-09-18 8:29 ` Yong Huang
2024-09-18 14:39 ` Fabiano Rosas
2024-09-15 16:08 ` [PATCH v1 4/7] migration: Implment background sync watcher Hyman Huang
2024-09-15 16:08 ` [PATCH v1 5/7] migration: Support background dirty bitmap sync and throttle Hyman Huang
2024-09-16 20:50 ` Fabiano Rosas
2024-09-15 16:08 ` [PATCH v1 6/7] qapi/migration: Introduce cpu-responsive-throttle parameter Hyman Huang
2024-09-16 20:55 ` Fabiano Rosas
2024-09-17 6:54 ` Yong Huang
2024-09-15 16:08 ` [PATCH v1 7/7] migration: Support responsive CPU throttle Hyman Huang
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=ZvW8LxJsv3pRWom_@x1n \
--to=peterx@redhat.com \
--cc=armbru@redhat.com \
--cc=david@redhat.com \
--cc=eblake@redhat.com \
--cc=farosas@suse.de \
--cc=pbonzini@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--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).