From: Juan Quintela <quintela@redhat.com>
To: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: qemu-devel@nongnu.org, "Leonardo Bras" <leobras@redhat.com>,
"Philippe Mathieu-Daudé" <f4bug@amsat.org>,
"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
"Eduardo Habkost" <eduardo@habkost.net>,
"Yanan Wang" <wangyanan55@huawei.com>
Subject: Re: [PATCH 1/5] multifd: Create property multifd-sync-each-iteration
Date: Mon, 04 Jul 2022 18:07:31 +0200 [thread overview]
Message-ID: <87h73w275o.fsf@secure.mitica> (raw)
In-Reply-To: <Yr20gdrEYimAq1Tn@work-vm> (David Alan Gilbert's message of "Thu, 30 Jun 2022 15:34:41 +0100")
"Dr. David Alan Gilbert" <dgilbert@redhat.com> wrote:
> * Juan Quintela (quintela@redhat.com) wrote:
>> We used to synchronize all channels at the end of each RAM section
>> sent. That is not needed, so preparing to only synchronize once every
>> full round in latests patches.
>>
>> Notice that we initialize the property as true. We will change the
>> default when we introduce the new mechanism.
>
> I don't understand why this is a property - does it break the actual
> stream format?
Yeap.
You can see on following patches. The problem is that we synchronize
each time that we sent/receive a
RAM_SAVE_FLAG_EOS
And that is way too much. As Leo showed, it can be as much as 20 times
a second.
Later, Juan.
next prev parent reply other threads:[~2022-07-04 16:10 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-21 14:05 [PATCH 0/5] Eliminate multifd flush Juan Quintela
2022-06-21 14:05 ` [PATCH 1/5] multifd: Create property multifd-sync-each-iteration Juan Quintela
2022-06-30 14:34 ` Dr. David Alan Gilbert
2022-07-04 16:07 ` Juan Quintela [this message]
2022-07-05 12:19 ` Dr. David Alan Gilbert
2022-06-21 14:05 ` [PATCH 2/5] multifd: Put around all sync calls tests for each iteration Juan Quintela
2022-07-05 12:20 ` Dr. David Alan Gilbert
2022-06-21 14:05 ` [PATCH 3/5] migration: Simplify ram_find_and_save_block() Juan Quintela
2022-07-05 12:51 ` Dr. David Alan Gilbert
2022-06-21 14:05 ` [PATCH 4/5] migration: Make find_dirty_block() return a single parameter Juan Quintela
2022-07-05 12:54 ` Dr. David Alan Gilbert
2022-07-26 16:23 ` Juan Quintela
2022-07-28 9:07 ` Dr. David Alan Gilbert
2022-06-21 14:05 ` [PATCH 5/5] multifd: Only sync once each full round of memory Juan Quintela
2022-07-01 2:29 ` Leonardo Brás
2022-07-04 16:18 ` Juan Quintela
2022-07-05 13:56 ` Dr. David Alan Gilbert
2022-07-05 14:34 ` Daniel P. Berrangé
2022-07-05 15:13 ` Juan Quintela
2022-07-05 15:11 ` Juan Quintela
2022-07-05 16:52 ` Daniel P. Berrangé
2022-07-05 17:13 ` Dr. David Alan Gilbert
2022-07-05 17:16 ` Daniel P. Berrangé
2022-07-05 17:20 ` Dr. David Alan Gilbert
2022-07-28 8:25 ` Juan Quintela
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=87h73w275o.fsf@secure.mitica \
--to=quintela@redhat.com \
--cc=dgilbert@redhat.com \
--cc=eduardo@habkost.net \
--cc=f4bug@amsat.org \
--cc=leobras@redhat.com \
--cc=marcel.apfelbaum@gmail.com \
--cc=qemu-devel@nongnu.org \
--cc=wangyanan55@huawei.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.