[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimiz
From: |
Dr. David Alan Gilbert |
Subject: |
Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization |
Date: |
Tue, 15 Mar 2016 19:55:16 +0000 |
User-agent: |
Mutt/1.5.24 (2015-08-30) |
* Li, Liang Z (address@hidden) wrote:
> > On Mon, Mar 14, 2016 at 05:03:34PM +0000, Dr. David Alan Gilbert wrote:
> > > * Li, Liang Z (address@hidden) wrote:
> > > > >
> > > > > Hi,
> > > > > I'm just catching back up on this thread; so without reference
> > > > > to any particular previous mail in the thread.
> > > > >
> > > > > 1) How many of the free pages do we tell the host about?
> > > > > Your main change is telling the host about all the
> > > > > free pages.
> > > >
> > > > Yes, all the guest's free pages.
> > > >
> > > > > If we tell the host about all the free pages, then we might
> > > > > end up needing to allocate more pages and update the host
> > > > > with pages we now want to use; that would have to wait for the
> > > > > host to acknowledge that use of these pages, since if we don't
> > > > > wait for it then it might have skipped migrating a page we
> > > > > just started using (I don't understand how your series solves
> > > > > that).
> > > > > So the guest probably needs to keep some free pages - how many?
> > > >
> > > > Actually, there is no need to care about whether the free pages will be
> > used by the host.
> > > > We only care about some of the free pages we get reused by the guest,
> > right?
> > > >
> > > > The dirty page logging can be used to solve this, starting the dirty
> > > > page logging before getting the free pages informant from guest.
> > > > Even some of the free pages are modified by the guest during the
> > > > process of getting the free pages information, these modified pages will
> > be traced by the dirty page logging mechanism. So in the following
> > migration_bitmap_sync() function.
> > > > The pages in the free pages bitmap, but latter was modified, will be
> > > > reset to dirty. We won't omit any dirtied pages.
> > > >
> > > > So, guest doesn't need to keep any free pages.
> > >
> > > OK, yes, that works; so we do:
> > > * enable dirty logging
> > > * ask guest for free pages
> > > * initialise the migration bitmap as everything-free
> > > * then later we do the normal sync-dirty bitmap stuff and it all just
> > > works.
> > >
> > > That's nice and simple.
> >
> > This works once, sure. But there's an issue is that you have to defer
> > migration
> > until you get the free page list, and this only works once. So you end up
> > with
> > heuristics about how long to wait.
> >
> > Instead I propose:
> >
> > - mark all pages dirty as we do now.
> >
> > - at start of migration, start tracking dirty
> > pages in kvm, and tell guest to start tracking free pages
> >
> > we can now introduce any kind of delay, for example wait for ack from guest,
> > or do whatever else, or even just start migrating pages
> >
> > - repeatedly:
> > - get list of free pages from guest
> > - clear them in migration bitmap
> > - get dirty list from kvm
> >
> > - at end of migration, stop tracking writes in kvm,
> > and tell guest to stop tracking free pages
>
> I had thought of filtering out the free pages in each migration bitmap
> synchronization.
> The advantage is we can skip process as many free pages as possible. Not just
> once.
> The disadvantage is that we should change the current memory management code
> to track the free pages,
> instead of traversing the free page list to construct the free pages bitmap,
> to reduce the overhead to get the free pages bitmap.
> I am not sure the if the Kernel people would like it.
>
> If keeping the traversing mechanism, because of the overhead, maybe it's not
> worth to filter out the free pages repeatedly.
Well, Michael's idea of not waiting for the dirty
bitmap to be filled does make that idea of constnatly
using the free-bitmap better.
In that case, is it easier if something (guest/host?)
allocates some memory in the guests physical RAM space
and just points the host to it, rather than having an
explicit 'send'.
Dave
> Liang
>
>
>
>
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK
- Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization, (continued)
- Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization, Li, Liang Z, 2016/03/08
- Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization, Li, Liang Z, 2016/03/10
- Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization, Amit Shah, 2016/03/10
- Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization, Li, Liang Z, 2016/03/10
- Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization, Dr. David Alan Gilbert, 2016/03/10
- Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization, Li, Liang Z, 2016/03/10
- Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization, Dr. David Alan Gilbert, 2016/03/14
- Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization, Li, Liang Z, 2016/03/14
- Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization, Michael S. Tsirkin, 2016/03/15
- Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization, Li, Liang Z, 2016/03/15
- Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization,
Dr. David Alan Gilbert <=
- Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization, Li, Liang Z, 2016/03/15
[Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization, Jitendra Kolhe, 2016/03/04