[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: |
Li, Liang Z |
Subject: |
Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization |
Date: |
Fri, 4 Mar 2016 09:08:44 +0000 |
> On Fri, Mar 04, 2016 at 01:52:53AM +0000, Li, Liang Z wrote:
> > > I wonder if it would be possible to avoid the kernel changes by
> > > parsing /proc/self/pagemap - if that can be used to detect
> > > unmapped/zero mapped pages in the guest ram, would it achieve the
> same result?
> >
> > Only detect the unmapped/zero mapped pages is not enough. Consider
> the
> > situation like case 2, it can't achieve the same result.
>
> Your case 2 doesn't exist in the real world. If people could stop their main
> memory consumer in the guest prior to migration they wouldn't need live
> migration at all.
The case 2 is just a simplified scenario, not a real case.
As long as the guest's memory usage does not keep increasing, or not always run
out,
it can be covered by the case 2.
> I tend to think you can safely assume there's no free memory in the guest, so
> there's little point optimizing for it.
If this is true, we should not inflate the balloon either.
> OTOH it makes perfect sense optimizing for the unmapped memory that's
> made up, in particular, by the ballon, and consider inflating the balloon
> right
> before migration unless you already maintain it at the optimal size for other
> reasons (like e.g. a global resource manager optimizing the VM density).
>
Yes, I believe the current balloon works and it's simple. Do you take the
performance impact for consideration?
For and 8G guest, it takes about 5s to inflating the balloon. But it only
takes 20ms to traverse the free_list and
construct the free pages bitmap. In this period, the guest are very busy.
By inflating the balloon, all the guest's pages are still be processed (zero
page checking).
The only advantage of ' inflating the balloon before live migration' is simple,
nothing more.
Liang
> Roman.
- [Qemu-devel] [RFC qemu 4/4] migration: filter out guest's free pages in ram bulk stage, (continued)
- [Qemu-devel] [RFC qemu 4/4] migration: filter out guest's free pages in ram bulk stage, Liang Li, 2016/03/03
- Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization, Roman Kagan, 2016/03/03
- Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization, Dr. David Alan Gilbert, 2016/03/03
- Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization, Li, Liang Z, 2016/03/03
- Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization, Roman Kagan, 2016/03/04
- Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization,
Li, Liang Z <=
- Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization, Roman Kagan, 2016/03/04
- Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization, Li, Liang Z, 2016/03/04
- Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization, Michael S. Tsirkin, 2016/03/04
- Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization, Li, Liang Z, 2016/03/04
- Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization, Michael S. Tsirkin, 2016/03/05
- Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization, Li, Liang Z, 2016/03/07
- Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization, Michael S. Tsirkin, 2016/03/07
- Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization, Li, Liang Z, 2016/03/07
- Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization, Roman Kagan, 2016/03/09
- Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization, Li, Liang Z, 2016/03/09