qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC PATCH 6/7] migration/multifd: Move payload storage out of the c


From: Fabiano Rosas
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

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 via email to

[Prev in Thread] Current Thread [Next in Thread]