Re: [Qemu-devel] [PATCH v6 00/11] rdma: migration support

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

OK, this looks excellent. I think we're ready for a PULL request now - I 
will submit to Juan - I've already got a signed-off from Paolo & Eric.
I think we've got sufficient testing now.

I'm expecting to get access to a big machine in the next week or two 
(256G machine) - and I should be able to reproduce your mlock() delay 
issue at that time.
With such a big VM - I think pinning will help you significantly.

Stay tuned,

- Michael

On 06/06/2013 07:51 PM, Chegu Vinod wrote:
>
>>
> Hi Michael,
>
> Got some limited time on the systems so gave your latest bits a quick 
> try today (with the default no pinning) and it seems to be better than 
> before.
>
> Ran a Java warehouse workload where the guest was 85-90% busy...
>
> For both cases
> (qemu) migrate_set_speed 40G
> (qemu) migrate_set_downtime 2
> (qemu) migrate -d x-rdma:<ip>:<port>
>
> ...
>
> 20VCPU/256G guest
>
> (qemu) info migrate
> capabilities: xbzrle: off x-rdma-pin-all: off
> Migration status: completed
> total time: 106994 milliseconds
> downtime: 3795 milliseconds
> transferred ram: 15425453 kbytes
> throughput: 20418.27 mbps
> remaining ram: 0 kbytes
> total ram: 268444224 kbytes
> duplicate: 64707112 pages
> skipped: 0 pages
> normal: 3839625 pages
> normal bytes: 15358500 kbytes
>
> ----
>
> 40VCPU/512G guest         <- I had more warehouse threads with higher 
> heap size etc. to make the guest busy...and hence it seems to have 
> taken a while to converge.
>
> (qemu) info migrate
> capabilities: xbzrle: off x-rdma-pin-all: off
> Migration status: completed
> total time: 2470056 milliseconds
> downtime: 6254 milliseconds
> transferred ram: 3230142002 kbytes
> throughput: 22118.67 mbps
> remaining ram: 0 kbytes
> total ram: 536879680 kbytes
> duplicate: 127436402 pages
> skipped: 0 pages
> normal: 807307274 pages
> normal bytes: 3229229096 kbytes
>
>
> <..>
>