[Top][All Lists]

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

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

From: Juan Quintela
Subject: Re: [PATCH 1/3] migration: In case of postcopy, the memory ends in res_postcopy_only
Date: Wed, 15 Feb 2023 10:08:18 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)

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

i.e. if we stop the guest and do the migration right now, what are we
going to send through each channel.

Later, Juan.

reply via email to

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