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

[Yoshiaki Tamura]

2011/2/24 Juan Quintela <address@hidden>:
> 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:-)

I'm with you at making live migration fast, but let me comment a
few.

> Basically, without an own thread we are not able to:
> - do anything else while on incoming migration
>  (namely using the monitor)

It's not true.  Just adding fixed headers to buffered file should
be enough for that.  I've done it for Kemari as you can see
this (http://www.osrg.net/kemari/download/kemari-v0.2-fedora11.mov).

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

I think current byte-based dirty bitmap for sending rams are
responsible for this too.  I've converted it to bit-based dirty
and made traversing 100x faster.  Also bypassing QEMUFile buffer
in case of rams would boost to some degrees.

Thanks,

Yoshi

> So, once code is there, I guess we will convince Anthony to commit it.
>
> Later, Juan.
>
>