qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Fabiano Rosas <farosas@suse.de>
To: Peter Xu <peterx@redhat.com>
Cc: "Wang, Lei" <lei4.wang@intel.com>,
	qemu-devel@nongnu.org,
	"Maciej S . Szmigiero" <mail@maciej.szmigiero.name>
Subject: Re: [RFC PATCH 6/7] migration/multifd: Move payload storage out of the channel parameters
Date: Thu, 18 Jul 2024 18:27:32 -0300	[thread overview]
Message-ID: <87frs61jcr.fsf@suse.de> (raw)
In-Reply-To: <ZpmFT9O-UN30i1F1@x1n>

Peter Xu <peterx@redhat.com> writes:

> On Thu, Jul 18, 2024 at 04:39:00PM -0300, Fabiano Rosas wrote:
>> v2 is ready, but unfortunately this approach doesn't work. When client A
>> takes the payload, it fills it with it's data, which may include
>> allocating memory. MultiFDPages_t does that for the offset. This means
>> we need a round of free/malloc at every packet sent. For every client
>> and every allocation they decide to do.
>
> Shouldn't be a blocker?  E.g. one option is:
>
>     /* Allocate both the pages + offset[] */
>     MultiFDPages_t *pages = g_malloc0(sizeof(MultiFDPages_t) +
>                                       sizeof(ram_addr_t) * n, 1);
>     pages->allocated = n;
>     pages->offset = &pages[1];
>
> Or.. we can also make offset[] dynamic size, if that looks less tricky:
>
> typedef struct {
>     /* number of used pages */
>     uint32_t num;
>     /* number of normal pages */
>     uint32_t normal_num;
>     /* number of allocated pages */
>     uint32_t allocated;
>     RAMBlock *block;
>     /* offset of each page */
>     ram_addr_t offset[0];
> } MultiFDPages_t;

I think you missed the point. If we hold a pointer inside the payload,
we lose the reference when the other client takes the structure and puts
its own data there. So we'll need to alloc/free everytime we send a
packet.


  reply	other threads:[~2024-07-18 21:28 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-20 21:21 [RFC PATCH 0/7] migration/multifd: Introduce storage slots Fabiano Rosas
2024-06-20 21:21 ` [RFC PATCH 1/7] migration/multifd: Reduce access to p->pages Fabiano Rosas
2024-06-21 14:42   ` Peter Xu
2024-06-20 21:21 ` [RFC PATCH 2/7] migration/multifd: Pass in MultiFDPages_t to file_write_ramblock_iov Fabiano Rosas
2024-06-20 21:21 ` [RFC PATCH 3/7] migration/multifd: Replace p->pages with an opaque pointer Fabiano Rosas
2024-06-20 21:21 ` [RFC PATCH 4/7] migration/multifd: Move pages accounting into multifd_send_zero_page_detect() Fabiano Rosas
2024-06-20 21:21 ` [RFC PATCH 5/7] migration/multifd: Isolate ram pages packet data Fabiano Rosas
2024-07-19 14:40   ` Fabiano Rosas
2024-06-20 21:21 ` [RFC PATCH 6/7] migration/multifd: Move payload storage out of the channel parameters Fabiano Rosas
2024-06-27  3:27   ` Wang, Lei
2024-06-27 14:40     ` Peter Xu
2024-06-27 15:17       ` Peter Xu
2024-07-10 16:10       ` Fabiano Rosas
2024-07-10 19:10         ` Peter Xu
2024-07-10 20:16           ` Fabiano Rosas
2024-07-10 21:55             ` Peter Xu
2024-07-11 14:12               ` Fabiano Rosas
2024-07-11 16:11                 ` Peter Xu
2024-07-11 19:37                   ` Fabiano Rosas
2024-07-11 20:27                     ` Peter Xu
2024-07-11 21:12                       ` Fabiano Rosas
2024-07-11 22:06                         ` Peter Xu
2024-07-12 12:44                           ` Fabiano Rosas
2024-07-12 15:37                             ` Peter Xu
2024-07-18 19:39                   ` Fabiano Rosas
2024-07-18 21:12                     ` Peter Xu
2024-07-18 21:27                       ` Fabiano Rosas [this message]
2024-07-18 21:52                         ` Peter Xu
2024-07-18 22:32                           ` Fabiano Rosas
2024-07-19 14:04                             ` Peter Xu
2024-07-19 16:54                               ` Fabiano Rosas
2024-07-19 17:58                                 ` Peter Xu
2024-07-19 21:30                                   ` Fabiano Rosas
2024-07-16 20:10             ` Maciej S. Szmigiero
2024-07-17 19:00               ` Peter Xu
2024-07-17 21:07                 ` Maciej S. Szmigiero
2024-07-17 21:30                   ` Peter Xu
2024-06-20 21:21 ` [RFC PATCH 7/7] migration/multifd: Hide multifd slots implementation Fabiano Rosas
2024-06-21 14:44 ` [RFC PATCH 0/7] migration/multifd: Introduce storage slots Maciej S. Szmigiero
2024-06-21 15:04   ` Fabiano Rosas
2024-06-21 15:31     ` Maciej S. Szmigiero
2024-06-21 15:56       ` Peter Xu
2024-06-21 17:40         ` Maciej S. Szmigiero
2024-06-21 20:54           ` Peter Xu
2024-06-23 20:25             ` Maciej S. Szmigiero
2024-06-23 20:45               ` 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=87frs61jcr.fsf@suse.de \
    --to=farosas@suse.de \
    --cc=lei4.wang@intel.com \
    --cc=mail@maciej.szmigiero.name \
    --cc=peterx@redhat.com \
    --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 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).