Re: [Qemu-devel] [PATCH v7 00/12] rdma: migration support

["Michael R. Hines" <mrhines@linux.vnet.ibm.com>]

On 06/13/2013 09:50 AM, Chegu Vinod wrote:
>
> Attempted to migrate a smaller guest 10Vcpu/64GB  (the guest was just 
> idle) with the pin-all option.
>
> It took ~20 sec to do the pin of the guest's RAM (this is the time 
> when the guest is "frozen") and then the actual migration started... 
> and took about ~26 secs to complete..  i.e. "info migrate" reported 
> the total migration time as ~26secs.
>
> From a user point of view the total clock time from when the migration 
> operation was actually initiated to the time the guest resumed on the 
> target host it was : ~20 + ~26 = ~46 secs ...hence my question.
>

(CC'ing qemu-devel, now.)

Ah, ok, yes, I see now - that's a bug that I would recommend reporting 
to the QEMU maintainer, actually:

Here is the sequence of events inside of QEMU:

1. issue the migrate command on the QEMU monitor:
2. qmp_migrate() gets called
3. (tcp|rdma|unix|etc)_start_outgoing_migration() gets called <= pinning 
occurs here
4. start migration_thread() 
pthread()                                           <= take first timestamp
5. migration complete                   <= take another timestamp and 
subtract for total time
6. exit migration_thread()

The problem, as you can see is that "take first timestamp" needs to 
happen earlier in step #2.

This is definitely a "nuisance", but not specific to RDMA, and I think a 
patch should be submitted, probably
by one of the maintainers which moves the timestamp up to a higher level.

Does that make sense?

- Michael