Yoshiaki Tamura <tamura.yoshi...@lab.ntt.co.jp> wrote: > 2011/2/23 Juan Quintela <quint...@redhat.com>: >> Yoshiaki Tamura <tamura.yoshi...@lab.ntt.co.jp> wrote: >>> 2011/2/23 Juan Quintela <quint...@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:-) 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.
