Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1354897

RE: [Qemu-devel] [RFC kernel 0/2]A PV solution for KVM live migration optimization

From "Li, Liang Z" <liang.z.li@intel.com>
Newsgroups linux.kernel
Subject RE: [Qemu-devel] [RFC kernel 0/2]A PV solution for KVM live migration optimization
Date 2016-03-10 08:30 +0100
Message-ID <rb3cK-3AY-9@gated-at.bofh.it> (permalink)
References <rb2To-3sO-19@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


> On 3/8/2016 4:44 PM, Amit Shah wrote:
> > On (Fri) 04 Mar 2016 [15:02:47], Jitendra Kolhe wrote:
> >>>>
> >>>> * Liang Li (liang.z.li@intel.com) wrote:
> >>>>> The current QEMU live migration implementation mark the all the
> >>>>> guest's RAM pages as dirtied in the ram bulk stage, all these
> >>>>> pages will be processed and that takes quit a lot of CPU cycles.
> >>>>>
> >>>>> From guest's point of view, it doesn't care about the content in
> >>>>> free pages. We can make use of this fact and skip processing the
> >>>>> free pages in the ram bulk stage, it can save a lot CPU cycles and
> >>>>> reduce the network traffic significantly while speed up the live
> >>>>> migration process obviously.
> >>>>>
> >>>>> This patch set is the QEMU side implementation.
> >>>>>
> >>>>> The virtio-balloon is extended so that QEMU can get the free pages
> >>>>> information from the guest through virtio.
> >>>>>
> >>>>> After getting the free pages information (a bitmap), QEMU can use
> >>>>> it to filter out the guest's free pages in the ram bulk stage.
> >>>>> This make the live migration process much more efficient.
> >>>>
> >>>> Hi,
> >>>>   An interesting solution; I know a few different people have been
> >>>> looking at how to speed up ballooned VM migration.
> >>>>
> >>>
> >>> Ooh, different solutions for the same purpose, and both based on the
> balloon.
> >>
> >> We were also tying to address similar problem, without actually
> >> needing to modify the guest driver. Please find patch details under mail
> with subject.
> >> migration: skip sending ram pages released by virtio-balloon driver
> >
> > The scope of this patch series seems to be wider: don't send free
> > pages to a dest at all, vs. don't send pages that are ballooned out.
> >
> > 		Amit
> 
> Hi,
> 
> Thanks for your response. The scope of this patch series doesn’t seem to
> take care of ballooned out pages. To balloon out a guest ram page the guest
> balloon driver does a alloc_page() and then return the guest pfn to Qemu, so
> ballooned out pages will not be seen as free ram pages by the guest.
> Thus we will still end up scanning (for zero page) for ballooned out pages
> during migration. It would be ideal if we could have both solutions.
> 

Agree,  for users who care about the performance, just skipping the free pages.
For users who have already turned on virtio-balloon,  your solution can take effect.

Liang
> Thanks,
> - Jitendra

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: [Qemu-devel] [RFC kernel 0/2]A PV solution for KVM live migration optimization Jitendra Kolhe <jitendra.kolhe@hpe.com> - 2016-03-10 08:10 +0100
  RE: [Qemu-devel] [RFC kernel 0/2]A PV solution for KVM live  migration optimization "Li, Liang Z" <liang.z.li@intel.com> - 2016-03-10 08:30 +0100
  Re: [Qemu-devel] [RFC kernel 0/2]A PV solution for KVM live  migration optimization Amit Shah <amit.shah@redhat.com> - 2016-03-10 08:40 +0100

csiph-web