Re: [Qemu-devel] [PATCH v2 00/41] postcopy live migration

[Avi Kivity]

On 06/08/2012 01:16 PM, Juan Quintela wrote:
> Anthony Liguori <address@hidden> wrote:
> >> TODO
> >> ====
> >> - benchmark/evaluation. Especially how async page fault affects the result.
> >
> > I don't mean to beat on a dead horse, but I really don't understand
> > the point of postcopy migration other than the fact that it's
> > possible.  It's a lot of code and a new ABI in an area where we
> > already have too much difficulty maintaining our ABI.
> >
> > Without a compelling real world case with supporting benchmarks for
> > why we need postcopy and cannot improve precopy, I'm against merging
> > this.
>
> I understand easily the need/want for post-copy migration.  Other thing
> is that this didn't came with benchmarks and that post-copy is
> difficult.
>
> The basic problem with precopy is that the amount of memory used by
> guest is not going to go down any time soon.  The same with number of
> cores.  At some point (it didn't matter if it is 16GB, 128GB or 256GB
> RAM in the guest, the same for vcpus), precopy just don't have a chance.
> And post-copy does.
>
> Once told that, we need to measure what is the time of an async page
> fault over the network.  If it is too high, post copy just don't work.
>
> And no, I haven't seen any measurement that told us that this is going
> to be fast enough, but there is always hope.

At 10Gb/sec, the time to transfer one page is 4 microseconds.  At
40Gb/sec this drops to a microsecond, plus the latency.  This is on par
with the time to handle a write protection fault that precopy uses.  But
this can *only* be achieved with RDMA, otherwise the overhead of
messaging and copying will dominate.

Note this does not mean we should postpone merging until RDMA support is
ready.  However we need to make sure the kernel interface is RDMA friendly.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.