[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH v2 6/9] migration/multifd: Move pages accounting into mul
From: |
Peter Xu |
Subject: |
Re: [RFC PATCH v2 6/9] migration/multifd: Move pages accounting into multifd_send_zero_page_detect() |
Date: |
Mon, 22 Jul 2024 16:38:36 -0400 |
On Mon, Jul 22, 2024 at 05:07:57PM -0300, Fabiano Rosas wrote:
> Peter Xu <peterx@redhat.com> writes:
>
> > On Mon, Jul 22, 2024 at 02:59:11PM -0300, Fabiano Rosas wrote:
> >> All references to pages are being removed from the multifd worker
> >> threads in order to allow multifd to deal with different payload
> >> types.
> >>
> >> multifd_send_zero_page_detect() is called by all multifd migration
> >> paths that deal with pages and is the last spot where zero pages and
> >> normal page amounts are adjusted. Move the pages accounting into that
> >> function.
> >
> > True, but it's a bit hackish to update (especially, normal) page counters
> > in a zero page detect function.
>
> Hm, that's the one place in the code that actually sets
> normal_num. Seems adequate to me.
Fair point.
>
> > I understand you want to move pages out of the thread function, that's
> > fair. How about put it in your new multifd_ram_fill_packet()?
> >
>
> That one is skipped when mapped-ram is in use. I could move it to
> nocomp_send_prepare() after the zero_page_detect. It seems we're moving
> towards changing nocomp -> ram at some point anyway. Would that be
> better? It would duplicate the call due to the compression code.
Maybe it's simply that the helper itself (multifd_send_zero_page_detect)
needs a better name (perhaps multifd_send_ram_setup()?). I'm ok we leave
this one as-is:
Reviewed-by: Peter Xu <peterx@redhat.com>
--
Peter Xu
[RFC PATCH v2 8/9] migration/multifd: Don't send ram data during SYNC, Fabiano Rosas, 2024/07/22
[RFC PATCH v2 9/9] migration/multifd: Replace multifd_send_state->pages with client data, Fabiano Rosas, 2024/07/22