All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: Fabiano Rosas <farosas@suse.de>
Cc: qemu-devel@nongnu.org,
	"Maciej S . Szmigiero" <mail@maciej.szmigiero.name>
Subject: Re: [RFC PATCH v2 8/9] migration/multifd: Don't send ram data during SYNC
Date: Mon, 22 Jul 2024 17:03:02 -0400	[thread overview]
Message-ID: <Zp7JBmVqMYw7rOT9@x1n> (raw)
In-Reply-To: <20240722175914.24022-9-farosas@suse.de>

On Mon, Jul 22, 2024 at 02:59:13PM -0300, Fabiano Rosas wrote:
> Skip saving and loading any ram data in the packet in the case of a
> SYNC. This fixes a shortcoming of the current code which requires a
> reset of the MultiFDPages_t fields right after the previous
> pending_job finishes, otherwise the very next job might be a SYNC and
> multifd_send_fill_packet() will put the stale values in the packet.
> 
> By not calling multifd_ram_fill_packet(), we can stop resetting
> MultiFDPages_t in the multifd core and leave that to the client code.
> 
> Actually moving the reset function is not yet done because
> pages->num==0 is used by the client code to determine whether the
> MultiFDPages_t needs to be flushed. The subsequent patches will
> replace that with a generic flag that is not dependent on
> MultiFDPages_t.
> 
> Signed-off-by: Fabiano Rosas <farosas@suse.de>
> ---
>  migration/multifd.c | 12 ++++++++++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/migration/multifd.c b/migration/multifd.c
> index d25b8658b2..4394ca6ade 100644
> --- a/migration/multifd.c
> +++ b/migration/multifd.c
> @@ -438,6 +438,7 @@ void multifd_send_fill_packet(MultiFDSendParams *p)
>  {
>      MultiFDPacket_t *packet = p->packet;
>      uint64_t packet_num;
> +    bool sync_packet = p->flags & MULTIFD_FLAG_SYNC;
>  
>      memset(packet, 0, p->packet_len);
>  
> @@ -452,7 +453,9 @@ void multifd_send_fill_packet(MultiFDSendParams *p)
>  
>      p->packets_sent++;
>  
> -    multifd_ram_fill_packet(p);
> +    if (!sync_packet) {
> +        multifd_ram_fill_packet(p);
> +    }
>  
>      trace_multifd_send(p->id, packet_num,
>                         be32_to_cpu(packet->normal_pages),
> @@ -563,7 +566,12 @@ static int multifd_recv_unfill_packet(MultiFDRecvParams *p, Error **errp)
>      p->packet_num = be64_to_cpu(packet->packet_num);
>      p->packets_recved++;
>  
> -    ret = multifd_ram_unfill_packet(p, errp);
> +    if (p->flags & MULTIFD_FLAG_SYNC) {
> +        p->normal_num = 0;
> +        p->zero_num = 0;

Instead of this, I wonder whether we shouldn't touch those fields at all,
but:

diff --git a/migration/multifd.c b/migration/multifd.c
index 0a85951d58..55abd9a1ef 100644
--- a/migration/multifd.c
+++ b/migration/multifd.c
@@ -1547,7 +1547,9 @@ static void *multifd_recv_thread(void *opaque)
             flags = p->flags;
             /* recv methods don't know how to handle the SYNC flag */
             p->flags &= ~MULTIFD_FLAG_SYNC;
-            has_data = p->normal_num || p->zero_num;
+
+            if (!(flags & MULTIFD_FLAG_SYNC))
+                has_data = p->normal_num || p->zero_num;
             qemu_mutex_unlock(&p->mutex);
         } else {
             /*

> +    } else {
> +        ret = multifd_ram_unfill_packet(p, errp);
> +    }
>  
>      trace_multifd_recv(p->id, p->packet_num, p->normal_num, p->zero_num,
>                         p->flags, p->next_packet_size);
> -- 
> 2.35.3
> 

-- 
Peter Xu



  reply	other threads:[~2024-07-22 21:04 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-22 17:59 [RFC PATCH v2 0/9] migration/multifd: Remove multifd_send_state->pages Fabiano Rosas
2024-07-22 17:59 ` [RFC PATCH v2 1/9] migration/multifd: Reduce access to p->pages Fabiano Rosas
2024-07-22 17:59 ` [RFC PATCH v2 2/9] migration/multifd: Pass in MultiFDPages_t to file_write_ramblock_iov Fabiano Rosas
2024-07-22 19:21   ` Peter Xu
2024-07-22 17:59 ` [RFC PATCH v2 3/9] migration/multifd: Introduce MultiFDSendData Fabiano Rosas
2024-07-22 19:22   ` Peter Xu
2024-07-22 17:59 ` [RFC PATCH v2 4/9] migration/multifd: Make MultiFDPages_t:offset a flexible array member Fabiano Rosas
2024-07-22 19:20   ` Peter Xu
2024-07-22 20:36     ` Fabiano Rosas
2024-07-22 17:59 ` [RFC PATCH v2 5/9] migration/multifd: Replace p->pages with an union pointer Fabiano Rosas
2024-07-22 17:59 ` [RFC PATCH v2 6/9] migration/multifd: Move pages accounting into multifd_send_zero_page_detect() Fabiano Rosas
2024-07-22 19:29   ` Peter Xu
2024-07-22 20:07     ` Fabiano Rosas
2024-07-22 20:38       ` Peter Xu
2024-07-22 17:59 ` [RFC PATCH v2 7/9] migration/multifd: Isolate ram pages packet data Fabiano Rosas
2024-07-22 19:37   ` Peter Xu
2024-07-22 20:34     ` Fabiano Rosas
2024-07-22 21:06       ` Peter Xu
2024-07-24  9:30         ` Maciej S. Szmigiero
2024-07-22 17:59 ` [RFC PATCH v2 8/9] migration/multifd: Don't send ram data during SYNC Fabiano Rosas
2024-07-22 21:03   ` Peter Xu [this message]
2024-07-22 21:24     ` Fabiano Rosas
2024-07-22 17:59 ` [RFC PATCH v2 9/9] migration/multifd: Replace multifd_send_state->pages with client data Fabiano Rosas
2024-07-22 19:55   ` Peter Xu
2024-07-22 20:26     ` Fabiano Rosas
2024-07-22 20:41       ` Peter Xu
2024-07-22 19:58 ` [RFC PATCH v2 0/9] migration/multifd: Remove multifd_send_state->pages Peter Xu
2024-07-22 20:21   ` Fabiano Rosas
2024-07-22 20:54     ` Peter Xu
2024-07-22 21:20       ` Fabiano Rosas
2024-07-22 23:01         ` Peter Xu
2024-07-23 17:48           ` Fabiano Rosas
2024-07-23 18:20             ` Peter Xu
2024-07-23 20:50               ` Fabiano Rosas
2024-07-23 21:11                 ` Peter Xu

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=Zp7JBmVqMYw7rOT9@x1n \
    --to=peterx@redhat.com \
    --cc=farosas@suse.de \
    --cc=mail@maciej.szmigiero.name \
    --cc=qemu-devel@nongnu.org \
    /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.