Re: [PATCH 1/3] migration: In case of postcopy, the memory ends in res_postcopy_only

[Vladimir Sementsov-Ogievskiy]

On 15.02.23 12:08, Juan Quintela wrote:
> Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> wrote:
> > On 08.02.23 16:57, Juan Quintela wrote:
> > > So remove last assignation of res_compatible.
> >
> > I hoped for some description when asked to split it out :)
> >
> > > Signed-off-by: Juan Quintela <quintela@redhat.com>
> > > ---
> > >    migration/ram.c | 2 +-
> > >    1 file changed, 1 insertion(+), 1 deletion(-)
> > > diff --git a/migration/ram.c b/migration/ram.c
> > > index b966e148c2..85ccbf88ad 100644
> > > --- a/migration/ram.c
> > > +++ b/migration/ram.c
> > > @@ -3474,7 +3474,7 @@ static void ram_state_pending_exact(void *opaque,
> > >          if (migrate_postcopy_ram()) {
> > >            /* We can do postcopy, and all the data is postcopiable */
> > > -        *res_compatible += remaining_size;
> > > +        *res_postcopy_only += remaining_size;
> >
> > Actually, these "remaining_size" bytes are still compatible, i.e. we
> > can migrate these pending bytes in pre-copy, and we actually do it,
> > until user call migrate-start-postcopy, yes? But we exploit the fact
> > that, this change don't affect any logic, just name becomes
> > wrong.. Yes? Or I don't follow:/
>
> I think of this from this different angle:
> - if we are on precopy, we return on res_precopy everything (and nothing
>    on res_postcopy)
> - if we are on postcopy, we return on res_precopy what we _must_ sent
>    through precopy, and in res_postcopy what we can sent through
>    postcopy.
>
> i.e. if we stop the guest and do the migration right now, what are we
> going to send through each channel.

I understand.

I've introduced the division into three parts together with block-dirty-bitmap 
implementation, and it seemed significant to me that block-dirty-bitmap pending 
is postcopy_only in the sense that it can't be migrated before source stop, 
unlike RAM. But yes, it turns out that that's not significant for the generic 
migration algorithm, it works the same way for RAM and block-dirty-bitmap not 
distinguishing postcopy_only vs comaptible.

Anyway final documentation and new field names that you proposed are clean and 
correspond to the meaning which you have expected. And it avoids extra variable 
that I've introduced.

Haha. Looking at my old commit 4799502640e6a29d3 "migration: introduce postcopy-only 
pending" I see

-                              uint64_t *non_postcopiable_pending,
-                              uint64_t *postcopiable_pending);
+                              uint64_t *res_precopy_only,
+                              uint64_t *res_compatible,
+                              uint64_t *res_postcopy_only);

so, we just rollback my change, which actually was never necessary. And it was 
called like I've proposed in 03 discussion thread :) Still, must_precopy and 
can_postcopy are nicer.

--
Best regards,
Vladimir