[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v7 00/12] rdma: migration support
From: |
Michael R. Hines |
Subject: |
Re: [Qemu-devel] [PATCH v7 00/12] rdma: migration support |
Date: |
Thu, 13 Jun 2013 10:45:54 -0400 |
User-agent: |
Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 |
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
- [Qemu-devel] [PATCH v7 05/12] rdma: introduce qemu_file_mode_is_not_valid(), (continued)
- [Qemu-devel] [PATCH v7 05/12] rdma: introduce qemu_file_mode_is_not_valid(), mrhines, 2013/06/10
- [Qemu-devel] [PATCH v7 09/12] rdma: new QEMUFileOps hooks, mrhines, 2013/06/10
- [Qemu-devel] [PATCH v7 04/12] rdma: export throughput w/ MigrationStats QMP, mrhines, 2013/06/10
- [Qemu-devel] [PATCH v7 01/12] rdma: add documentation, mrhines, 2013/06/10
- [Qemu-devel] [PATCH v7 03/12] rdma: export yield_until_fd_readable(), mrhines, 2013/06/10
- [Qemu-devel] [PATCH v7 12/12] rdma: send pc.ram, mrhines, 2013/06/10
- [Qemu-devel] [PATCH v7 08/12] rdma: introduce qemu_ram_foreach_block(), mrhines, 2013/06/10
- [Qemu-devel] [PATCH v7 11/12] rdma: core logic, mrhines, 2013/06/10
- [Qemu-devel] [PATCH v7 06/12] rdma: export qemu_fflush(), mrhines, 2013/06/10
- [Qemu-devel] [PATCH v7 02/12] rdma: introduce qemu_update_position(), mrhines, 2013/06/10
- Message not available
- Message not available
- Message not available
- Message not available
- Message not available
- Message not available
- Message not available
- Message not available
- Message not available
- Re: [Qemu-devel] [PATCH v7 00/12] rdma: migration support,
Michael R. Hines <=
Message not available
- Message not available
- Message not available
- Message not available
- Message not available
- Message not available
- Message not available
- Message not available
- Message not available
- Re: [Qemu-devel] [PATCH v7 00/12] rdma: migration support, Michael R. Hines, 2013/06/13
- Re: [Qemu-devel] [PATCH v7 00/12] rdma: migration support, Paolo Bonzini, 2013/06/13
- Re: [Qemu-devel] [PATCH v7 00/12] rdma: migration support, Michael R. Hines, 2013/06/13
- Re: [Qemu-devel] [PATCH v7 00/12] rdma: migration support, Paolo Bonzini, 2013/06/13
- Re: [Qemu-devel] [PATCH v7 00/12] rdma: migration support, Michael R. Hines, 2013/06/14
- [Qemu-devel] RDMA: please pull and re-test freezing fixes, Michael R. Hines, 2013/06/14
- Re: [Qemu-devel] RDMA: please pull and re-test freezing fixes, Michael R. Hines, 2013/06/14
- Re: [Qemu-devel] RDMA: please pull and re-test freezing fixes, Chegu Vinod, 2013/06/15
- Re: [Qemu-devel] RDMA: please pull and re-test freezing fixes, Michael R. Hines, 2013/06/16