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

[Anthony Liguori <anthony@codemonkey.ws>]

On 02/24/2011 06:23 AM, Juan Quintela wrote:
> Yoshiaki Tamura<tamura.yoshiaki@lab.ntt.co.jp>  wrote:
>    
>> 2011/2/23 Juan Quintela<quintela@redhat.com>:
>>      
>>> Yoshiaki Tamura<tamura.yoshiaki@lab.ntt.co.jp>  wrote:
>>>        
>>>> 2011/2/23 Juan Quintela<quintela@redhat.com>:
>>>>          
>    
>>>> 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 :-)

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.

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.
>
>