Re: [Qemu-devel] Re: [PATCH 22/22] migration: Make state definitions local

[Yoshiaki Tamura]

2011/2/24 Anthony Liguori <address@hidden>:
> On 02/24/2011 06:23 AM, Juan Quintela wrote:
>>
>> Yoshiaki Tamura<address@hidden>  wrote:
>>
>>>
>>> 2011/2/23 Juan Quintela<address@hidden>:
>>>
>>>>
>>>> Yoshiaki Tamura<address@hidden>  wrote:
>>>>
>>>>>
>>>>> 2011/2/23 Juan Quintela<address@hidden>:
>>>>>
>>
>>
>>>>>
>>>>> Although you're right, I would prefer to keep it so that somebody
>>>>> outside of migration may understand the status in the future if
>>>>> there are no harms.
>>>>>
>>>>
>>>> my plan is to move MigrationState inside migration.c, and then decide
>>>> what to export/not export.
>>>>
>>>
>>> Well, it may be just a policy, but it's already exported, and I
>>> would like to keep it unless it bothers your plan.  IIUC, I don't
>>> think it does.
>>>
>>>
>>>>
>>>> Next thing to do is move migration to its
>>>> own thread.  Before doing that, I need to know what parts are used/not
>>>> used outside migration.c.  Removing it now means that nothing gets to
>>>> use it without needing a patch.
>>>>
>>>
>>> I've once asked Anthony whether it's possible to make migration
>>> to different threads, but his answer was no due to hard
>>> dependency of qemu's internal code, and making migration to
>>> different threads are bad design.
>>>
>>
>> I know.  But Anthony is seeing the light O:-)
>>
>
> Let's be very careful about quoting Anthony as he's known to be incoherent
> 90% of the time :-)

There you are :)

> I don't quite recall the context of the discussion with Yoshi, but I'm not
> quite there in terms of advocating that we throw a bucket full of threads at
> migration.  I think we should move the ram migration to another I/O thread
> that doesn't hold a lock against the main I/O thread.  That's all.

Let's just forget about the old discussion and have a new one.
Why do you want to have a new thread only for ram migration?  I
know that it's the majority of the migration, but how do you
serialize it with other device migration for single QEMUFile?
IIUC, it seems to get mixed up easily or lose paralism.

Thanks,

Yoshi

>
> Regards,
>
> Anthony Liguori
>
>> Basically, without an own thread we are not able to:
>> - do anything else while on incoming migration
>>   (namely using the monitor)
>> - do anything else than migration.  We can try hard and let vcpus to
>>   run, but we would still clog the io_thread.
>> - We are not able to saturate 10Gbit networking (basically we are doing
>>   2/3 level of bufferering (depending on how you count).
>>
>> So, once code is there, I guess we will convince Anthony to commit it.
>>
>> Later, Juan.
>>
>>
>
>
>