Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1350256
| From | "Li, Liang Z" <liang.z.li@intel.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | RE: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization |
| Date | 2016-03-04 15:30 +0100 |
| Message-ID | <r8YTT-810-3@gated-at.bofh.it> (permalink) |
| References | (1 earlier) <r8FxU-29v-5@gated-at.bofh.it> <r8Nc6-7Fq-19@gated-at.bofh.it> <r8T7P-3PF-3@gated-at.bofh.it> <r8TUf-4rg-35@gated-at.bofh.it> <r8V9E-5bS-11@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
> Subject: Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration > optimization > > On Fri, Mar 04, 2016 at 09:08:44AM +0000, Li, Liang Z wrote: > > > 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. > > The memory usage will keep increasing due to ever growing caches, etc, so > you'll be left with very little free memory fairly soon. > I don't think so. > > > 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. > > We certainly should if there's "available" memory, i.e. not free but cheap to > reclaim. > What's your mean by "available" memory? if they are not free, I don't think it's cheap. > > > 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. > > I don't have any feeling of how important the difference is. And if the > limiting factor for balloon inflation speed is the granularity of communication > it may be worth optimizing that, because quick balloon reaction may be > important in certain resource management scenarios. > > > By inflating the balloon, all the guest's pages are still be processed (zero > page checking). > > Not sure what you mean. If you describe the current state of affairs that's > exactly the suggested optimization point: skip unmapped pages. > You'd better check the live migration code. > > The only advantage of ' inflating the balloon before live migration' is simple, > nothing more. > > That's a big advantage. Another one is that it does something useful in real- > world scenarios. > I don't think the heave performance impaction is something useful in real world scenarios. Liang > Roman.
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[RFC qemu 0/4] A PV solution for live migration optimization Liang Li <liang.z.li@intel.com> - 2016-03-03 12:00 +0100
[RFC qemu 3/4] migration: not set migration bitmap in setup stage Liang Li <liang.z.li@intel.com> - 2016-03-03 12:00 +0100
[RFC qemu 1/4] pc: Add code to get the lowmem form PCMachineState Liang Li <liang.z.li@intel.com> - 2016-03-03 12:00 +0100
Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization Roman Kagan <rkagan@virtuozzo.com> - 2016-03-03 15:10 +0100
RE: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization "Li, Liang Z" <liang.z.li@intel.com> - 2016-03-04 02:40 +0100
Re: [RFC qemu 0/4] A PV solution for live migration optimization "Dr. David Alan Gilbert" <dgilbert@redhat.com> - 2016-03-03 18:50 +0100
RE: [RFC qemu 0/4] A PV solution for live migration optimization "Li, Liang Z" <liang.z.li@intel.com> - 2016-03-04 03:00 +0100
Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization Roman Kagan <rkagan@virtuozzo.com> - 2016-03-04 09:20 +0100
RE: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization "Li, Liang Z" <liang.z.li@intel.com> - 2016-03-04 10:10 +0100
Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization Roman Kagan <rkagan@virtuozzo.com> - 2016-03-04 11:30 +0100
RE: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization "Li, Liang Z" <liang.z.li@intel.com> - 2016-03-04 15:30 +0100
Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization "Michael S. Tsirkin" <mst@redhat.com> - 2016-03-04 15:50 +0100
RE: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization "Li, Liang Z" <liang.z.li@intel.com> - 2016-03-04 16:50 +0100
Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization "Michael S. Tsirkin" <mst@redhat.com> - 2016-03-05 21:00 +0100
RE: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization "Li, Liang Z" <liang.z.li@intel.com> - 2016-03-07 08:00 +0100
Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization "Michael S. Tsirkin" <mst@redhat.com> - 2016-03-07 12:50 +0100
RE: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization "Li, Liang Z" <liang.z.li@intel.com> - 2016-03-07 16:10 +0100
Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization Roman Kagan <rkagan@virtuozzo.com> - 2016-03-09 15:30 +0100
RE: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization "Li, Liang Z" <liang.z.li@intel.com> - 2016-03-09 16:30 +0100
Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization "Michael S. Tsirkin" <mst@redhat.com> - 2016-03-09 16:40 +0100
RE: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization "Li, Liang Z" <liang.z.li@intel.com> - 2016-03-10 02:50 +0100
Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization "Michael S. Tsirkin" <mst@redhat.com> - 2016-03-10 13:30 +0100
Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization "Michael S. Tsirkin" <mst@redhat.com> - 2016-03-09 16:50 +0100
Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization Roman Kagan <rkagan@virtuozzo.com> - 2016-03-09 18:10 +0100
Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization "Michael S. Tsirkin" <mst@redhat.com> - 2016-03-09 18:40 +0100
Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization Roman Kagan <rkagan@virtuozzo.com> - 2016-03-10 11:30 +0100
Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization Rik van Riel <riel@redhat.com> - 2016-03-09 20:40 +0100
Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization Roman Kagan <rkagan@virtuozzo.com> - 2016-03-10 10:40 +0100
Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization Paolo Bonzini <pbonzini@redhat.com> - 2016-03-04 17:30 +0100
Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization "Dr. David Alan Gilbert" <dgilbert@redhat.com> - 2016-03-04 20:00 +0100
RE: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization "Li, Liang Z" <liang.z.li@intel.com> - 2016-03-07 06:40 +0100
Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization Roman Kagan <rkagan@virtuozzo.com> - 2016-03-09 14:30 +0100
RE: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization "Li, Liang Z" <liang.z.li@intel.com> - 2016-03-09 15:20 +0100
RE: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization "Li, Liang Z" <liang.z.li@intel.com> - 2016-03-09 07:20 +0100
Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization Roman Kagan <rkagan@virtuozzo.com> - 2016-03-04 09:00 +0100
RE: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization "Li, Liang Z" <liang.z.li@intel.com> - 2016-03-04 09:30 +0100
Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization Roman Kagan <rkagan@virtuozzo.com> - 2016-03-04 09:40 +0100
Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization "Dr. David Alan Gilbert" <dgilbert@redhat.com> - 2016-03-04 10:10 +0100
RE: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization "Li, Liang Z" <liang.z.li@intel.com> - 2016-03-04 10:20 +0100
Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization "Michael S. Tsirkin" <mst@redhat.com> - 2016-03-04 10:50 +0100
RE: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization "Li, Liang Z" <liang.z.li@intel.com> - 2016-03-04 11:20 +0100
Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization "Michael S. Tsirkin" <mst@redhat.com> - 2016-03-04 11:40 +0100
RE: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization "Li, Liang Z" <liang.z.li@intel.com> - 2016-03-04 16:20 +0100
Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization "Michael S. Tsirkin" <mst@redhat.com> - 2016-03-08 15:10 +0100
RE: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization "Li, Liang Z" <liang.z.li@intel.com> - 2016-03-08 15:20 +0100
Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization Roman Kagan <rkagan@virtuozzo.com> - 2016-03-04 10:40 +0100
Re: [RFC qemu 0/4] A PV solution for live migration optimization Amit Shah <amit.shah@redhat.com> - 2016-03-08 12:20 +0100
RE: [RFC qemu 0/4] A PV solution for live migration optimization "Li, Liang Z" <liang.z.li@intel.com> - 2016-03-08 14:20 +0100
RE: [RFC qemu 0/4] A PV solution for live migration optimization "Li, Liang Z" <liang.z.li@intel.com> - 2016-03-10 08:50 +0100
Re: [RFC qemu 0/4] A PV solution for live migration optimization Amit Shah <amit.shah@redhat.com> - 2016-03-10 09:00 +0100
RE: [RFC qemu 0/4] A PV solution for live migration optimization "Li, Liang Z" <liang.z.li@intel.com> - 2016-03-10 09:40 +0100
Re: [RFC qemu 0/4] A PV solution for live migration optimization "Dr. David Alan Gilbert" <dgilbert@redhat.com> - 2016-03-10 12:20 +0100
RE: [RFC qemu 0/4] A PV solution for live migration optimization "Li, Liang Z" <liang.z.li@intel.com> - 2016-03-11 03:40 +0100
Re: [RFC qemu 0/4] A PV solution for live migration optimization "Dr. David Alan Gilbert" <dgilbert@redhat.com> - 2016-03-14 18:10 +0100
RE: [RFC qemu 0/4] A PV solution for live migration optimization "Li, Liang Z" <liang.z.li@intel.com> - 2016-03-15 04:40 +0100
Re: [RFC qemu 0/4] A PV solution for live migration optimization "Michael S. Tsirkin" <mst@redhat.com> - 2016-03-15 11:40 +0100
RE: [RFC qemu 0/4] A PV solution for live migration optimization "Li, Liang Z" <liang.z.li@intel.com> - 2016-03-15 12:20 +0100
Re: [RFC qemu 0/4] A PV solution for live migration optimization "Dr. David Alan Gilbert" <dgilbert@redhat.com> - 2016-03-15 21:00 +0100
RE: [RFC qemu 0/4] A PV solution for live migration optimization "Li, Liang Z" <liang.z.li@intel.com> - 2016-03-16 02:30 +0100
csiph-web