[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.
- Re: [RFC PATCH 6/7] migration/multifd: Move payload storage out of the channel parameters, (continued)
- Re: [RFC PATCH 6/7] migration/multifd: Move payload storage out of the channel parameters, Fabiano Rosas, 2024/07/11
- Re: [RFC PATCH 6/7] migration/multifd: Move payload storage out of the channel parameters, Peter Xu, 2024/07/11
- Re: [RFC PATCH 6/7] migration/multifd: Move payload storage out of the channel parameters, Fabiano Rosas, 2024/07/11
- Re: [RFC PATCH 6/7] migration/multifd: Move payload storage out of the channel parameters, Peter Xu, 2024/07/11
- Re: [RFC PATCH 6/7] migration/multifd: Move payload storage out of the channel parameters, Fabiano Rosas, 2024/07/11
- Re: [RFC PATCH 6/7] migration/multifd: Move payload storage out of the channel parameters, Peter Xu, 2024/07/11
- Re: [RFC PATCH 6/7] migration/multifd: Move payload storage out of the channel parameters, Fabiano Rosas, 2024/07/12
- Re: [RFC PATCH 6/7] migration/multifd: Move payload storage out of the channel parameters, Peter Xu, 2024/07/12
- Re: [RFC PATCH 6/7] migration/multifd: Move payload storage out of the channel parameters, Fabiano Rosas, 2024/07/18
- Re: [RFC PATCH 6/7] migration/multifd: Move payload storage out of the channel parameters, Peter Xu, 2024/07/18
- Re: [RFC PATCH 6/7] migration/multifd: Move payload storage out of the channel parameters,
Fabiano Rosas <=
- Re: [RFC PATCH 6/7] migration/multifd: Move payload storage out of the channel parameters, Peter Xu, 2024/07/18
- Re: [RFC PATCH 6/7] migration/multifd: Move payload storage out of the channel parameters, Fabiano Rosas, 2024/07/18
- Re: [RFC PATCH 6/7] migration/multifd: Move payload storage out of the channel parameters, Peter Xu, 2024/07/19
- Re: [RFC PATCH 6/7] migration/multifd: Move payload storage out of the channel parameters, Fabiano Rosas, 2024/07/19
- Re: [RFC PATCH 6/7] migration/multifd: Move payload storage out of the channel parameters, Peter Xu, 2024/07/19
- Re: [RFC PATCH 6/7] migration/multifd: Move payload storage out of the channel parameters, Fabiano Rosas, 2024/07/19
- Re: [RFC PATCH 6/7] migration/multifd: Move payload storage out of the channel parameters, Maciej S. Szmigiero, 2024/07/16
- Re: [RFC PATCH 6/7] migration/multifd: Move payload storage out of the channel parameters, Peter Xu, 2024/07/17
- Re: [RFC PATCH 6/7] migration/multifd: Move payload storage out of the channel parameters, Maciej S. Szmigiero, 2024/07/17
- Re: [RFC PATCH 6/7] migration/multifd: Move payload storage out of the channel parameters, Peter Xu, 2024/07/17