Re: [Qemu-devel] Memory sync algorithm during migration

[Oliver Hookins]

On Tue, Nov 15, 2011 at 11:47:58AM +0100, ext Juan Quintela wrote:
> Takuya Yoshikawa <address@hidden> wrote:
> > Adding qemu-devel ML to CC.
> >
> > Your question should have been sent to qemu-devel ML because the logic
> > is implemented in QEMU, not KVM.
> >
> > (2011/11/11 1:35), Oliver Hookins wrote:
> >> Hi,
> >>
> >> I am performing some benchmarks on KVM migration on two different types of 
> >> VM.
> >> One has 4GB RAM and the other 32GB. More or less idle, the 4GB VM takes 
> >> about 20
> >> seconds to migrate on our hardware while the 32GB VM takes about a minute.
> >>
> >> With a reasonable amount of memory activity going on (in the hundreds of 
> >> MB per
> >> second) the 32GB VM takes 3.5 minutes to migrate, but the 4GB VM never
> >> completes. Intuitively this tells me there is some watermarking of dirty 
> >> pages
> >> going on that is not particularly efficient when the dirty pages ratio is 
> >> high
> >> compared to total memory, but I may be completely incorrect.
> 
> > You can change the ratio IIRC.
> > Hopefully, someone who knows well about QEMU will tell you better ways.
> >
> >     Takuya
> >
> >>
> >> Could anybody fill me in on what might be going on here? We're using 
> >> libvirt
> >> 0.8.2 and kvm-83-224.el5.centos.1
> 
> This is pretty old qemu/kvm code base.
> In principle, it makes no sense that with 32GB RAM migration finishes,
> and with 4GB RAM it is unable (intuitively it should be, if ever, the
> other way around).

If the syncing of dirty pages is based on some kind of ratio that causes it to
resync everything if more than a certain percentage of total pages are dirty
then this could explain it, as with a smaller amount of memory it could be
continually restarting.

I can certainly state from observation that the network traffic continues at
high speed the whole time so perhaps this makes some sense. I was hoping that
this behaviour would cause someone to recall a problem like this that was solved
- maybe this is not the case!

> 
> Do you have an easy test that makes the problem easily reproducible?
> Have you tried ustream qemu.git? (some improvements on that department).

I haven't just yet, but I'll give this a try. Thanks for the suggestion!