Re: [Qemu-devel] [PATCH 0/17 v2] Localhost migration with side channel for ram

[Lei Li]

On 10/24/2013 10:17 PM, Paolo Bonzini wrote:
> Il 22/10/2013 04:25, Lei Li ha scritto:
> > This patch series tries to introduce a mechanism using side
> > channel pipe for RAM via SCM_RIGHTS with unix domain socket
> > protocol migration.
> >
> > This side channel is used for the page flipping by vmsplice,
> > which is the internal mechanism for localhost migration that
> > we are trying to add to QEMU. The backgroud info and previous
> > patch series for reference,
> >
> > Localhost migration
> > http://lists.nongnu.org/archive/html/qemu-devel/2013-08/msg02916.html
> >
> > migration: Introduce side channel for RAM
> > http://lists.gnu.org/archive/html/qemu-devel/2013-09/msg04043.html
> >
> > I have picked patches from the localhost migration series and rebased
> > it on the series of side channel, now it is a complete series that
> > passed the basic test.
> >
> > Please let me know if there is anything needs to be fixed or improved.
> > Your suggestions and comments are very welcome, and thanks for Paolo
> > for his review and useful suggestions.
> Thanks to you for listening. :)
>
> What is performance like?  How much downtime do you get as the guest
> size increases?

Hi Paolo,

Thanks very much for your continued reviews, as well as those nice suggestions
and comments!

For the performance, we have not yet benchmarked it from QEMU layer, as now it's
just an initial implementation, and Robert Jennings has been worked on the
improvement of performance on kernel side.

Right now just has inaccurate numbers without the new vmsplice, which based on
the result from info migrate, as the guest ram size increases, although the
'total time' is number of times less compared with the current live migration,
but the 'downtime' performs badly.

For a 1GB ram guest,

total time: 702 milliseconds
downtime: 692 milliseconds

And when the ram size of guest increasesexponentially, those numbers are
proportional to it.
 
I will make a list of the performance with the new vmsplice later, I am sure
it'd be much better than this at least.

> Paolo


--
Lei