From: Juan Quintela <quintela@redhat.com>
To: Peter Xu <peterx@redhat.com>
Cc: Wei Yang <richardw.yang@linux.intel.com>,
dgilbert@redhat.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] migratioin/ram.c: reset complete_round when we gets a queued page
Date: Wed, 05 Jun 2019 12:33:39 +0200 [thread overview]
Message-ID: <87d0js5njw.fsf@trasno.org> (raw)
In-Reply-To: <20190605093819.GL15459@xz-x1> (Peter Xu's message of "Wed, 5 Jun 2019 17:38:19 +0800")
Peter Xu <peterx@redhat.com> wrote:
> On Wed, Jun 05, 2019 at 04:52:07PM +0800, Wei Yang wrote:
>> On Wed, Jun 05, 2019 at 02:41:08PM +0800, Peter Xu wrote:
>> >On Wed, Jun 05, 2019 at 09:08:28AM +0800, Wei Yang wrote:
>> >> In case we gets a queued page, the order of block is interrupted. We may
>> >> not rely on the complete_round flag to say we have already searched the
>> >> whole blocks on the list.
>> >>
>> >> Signed-off-by: Wei Yang <richardw.yang@linux.intel.com>
>> >> ---
>> >> migration/ram.c | 6 ++++++
>> >> 1 file changed, 6 insertions(+)
>> >>
>> >> diff --git a/migration/ram.c b/migration/ram.c
>> >> index d881981876..e9b40d636d 100644
>> >> --- a/migration/ram.c
>> >> +++ b/migration/ram.c
>> >> @@ -2290,6 +2290,12 @@ static bool get_queued_page(RAMState *rs, PageSearchStatus *pss)
>> >> */
>> >> pss->block = block;
>> >> pss->page = offset >> TARGET_PAGE_BITS;
>> >> +
>> >> + /*
>> >> + * This unqueued page would break the "one round" check, even is
>> >> + * really rare.
>> >
> Ah I see your point, but I don't think there is a problem - note that
> complete_round will be reset for each ram_find_and_save_block(), so
> even if we have that iteration of ram_find_and_save_block() to return
> we'll still know we have dirty pages to migrate and in the next call
> we'll be fine, no?
Reviewed-by: Juan Quintela <quintela@redhat.com>
I *think* that peter is perhaps right, but it is not clear at all, and
it is easier to be safe. I think that the only case that this could
matter is if:
- all pages are clean (so complete_round will get as true)
- we went a queue_page request
Is that possible? I am not completely sure after looking at the code.
It *could* be if the page that got queued is the last page remaining,
but ...... I fully agree that the case that _almost all_ pages are
clean and we get a request for a queued page is really rare, so it
should not matter in real life, but ....
Later, Juan.
next prev parent reply other threads:[~2019-06-05 10:35 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-05 1:08 [Qemu-devel] [PATCH] migratioin/ram.c: reset complete_round when we gets a queued page Wei Yang
2019-06-05 6:41 ` Peter Xu
2019-06-05 8:52 ` Wei Yang
2019-06-05 9:38 ` Peter Xu
2019-06-05 10:33 ` Juan Quintela [this message]
2019-06-05 13:39 ` Wei Yang
2019-06-05 13:41 ` Wei Yang
2019-06-05 12:27 ` Philippe Mathieu-Daudé
2019-06-05 13:39 ` Wei Yang
2019-06-05 14:11 ` Philippe Mathieu-Daudé
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=87d0js5njw.fsf@trasno.org \
--to=quintela@redhat.com \
--cc=dgilbert@redhat.com \
--cc=peterx@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=richardw.yang@linux.intel.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.