search for: qemu_balloon_is_inhibited

...dr(pa); > + memory_region_unref(section.mr); > + continue; > + } > > - trace_virtio_balloon_handle_output(memory_region_name(section.mr), > - pa); > - if (!qemu_balloon_is_inhibited()) { > - if (vq == s->ivq) { > - balloon_inflate_page(s, section.mr, > - section.offset_within_region, &pbp); > - } else if (vq == s->dvq) { > - balloon_deflate_page(...

...sume we are saying either > poison_val or unmodified? If so I would think the inflate case makes > much more sense as that is where the madvise is called that will > discard the data. If so it would be pretty easy to just add a check > for the poison value to the same spot we check > qemu_balloon_is_inhibited. Okay, we have basically no idea what was the intention of VIRTIO_BALLOON_F_PAGE_POISON with basic deflation/inflation as well. So I think we can define what suits us. On the deflate path, we could always simply fill with poison_val. But there are nasty corner cases (esp. no VIRTIO_BALLOON_F_MUST...

...oison_val or unmodified? If so I would think the inflate case makes >>> much more sense as that is where the madvise is called that will >>> discard the data. If so it would be pretty easy to just add a check >>> for the poison value to the same spot we check >>> qemu_balloon_is_inhibited. >> >> Okay, we have basically no idea what was the intention of >> VIRTIO_BALLOON_F_PAGE_POISON with basic deflation/inflation as well. So >> I think we can define what suits us. >> >> On the deflate path, we could always simply fill with poison_val. But >&gt...

...Gilbert wrote: > Hi, > I was reading the balloon code and am confused as to how/if ballooning > works on hosts where the host page size is larger than the > target page size. > > static void balloon_page(void *addr, int deflate) > { > #if defined(__linux__) > if (!qemu_balloon_is_inhibited() && (!kvm_enabled() || > kvm_has_sync_mmu())) { > qemu_madvise(addr, TARGET_PAGE_SIZE, > deflate ? QEMU_MADV_WILLNEED : QEMU_MADV_DONTNEED); > } > #endif > } > > The virtio-balloon code only does...

...Gilbert wrote: > Hi, > I was reading the balloon code and am confused as to how/if ballooning > works on hosts where the host page size is larger than the > target page size. > > static void balloon_page(void *addr, int deflate) > { > #if defined(__linux__) > if (!qemu_balloon_is_inhibited() && (!kvm_enabled() || > kvm_has_sync_mmu())) { > qemu_madvise(addr, TARGET_PAGE_SIZE, > deflate ? QEMU_MADV_WILLNEED : QEMU_MADV_DONTNEED); > } > #endif > } > > The virtio-balloon code only does...

...addr, > !!(vq == s->dvq)); > memory_region_unref(section.mr); > } > > so all that happens when we get a page is balloon_page. > and > > static void balloon_page(void *addr, int deflate) { #if defined(__linux__) > if (!qemu_balloon_is_inhibited() && (!kvm_enabled() || > kvm_has_sync_mmu())) { > qemu_madvise(addr, TARGET_PAGE_SIZE, > deflate ? QEMU_MADV_WILLNEED : QEMU_MADV_DONTNEED); > } > #endif > } > > > Do you see anything that tra...

...addr, > !!(vq == s->dvq)); > memory_region_unref(section.mr); > } > > so all that happens when we get a page is balloon_page. > and > > static void balloon_page(void *addr, int deflate) { #if defined(__linux__) > if (!qemu_balloon_is_inhibited() && (!kvm_enabled() || > kvm_has_sync_mmu())) { > qemu_madvise(addr, TARGET_PAGE_SIZE, > deflate ? QEMU_MADV_WILLNEED : QEMU_MADV_DONTNEED); > } > #endif > } > > > Do you see anything that tra...

>>> 2. Can we assume that the guest will always rewrite the page after the >>> deflate in the case of init_on_free or poison? >> >> Depends on what we think is the right way to do - IOW if we think "some >> other content" as mentioned above is a BUG or not. > > So I wouldn't consider it a but as the zero page probably doesn't > apply.

...> > poison_val or unmodified? If so I would think the inflate case makes > > much more sense as that is where the madvise is called that will > > discard the data. If so it would be pretty easy to just add a check > > for the poison value to the same spot we check > > qemu_balloon_is_inhibited. > > Okay, we have basically no idea what was the intention of > VIRTIO_BALLOON_F_PAGE_POISON with basic deflation/inflation as well. So > I think we can define what suits us. > > On the deflate path, we could always simply fill with poison_val. But > there are nasty corner cas...

..._page(memory_region_get_ram_ptr(section.mr) + addr, !!(vq == s->dvq)); memory_region_unref(section.mr); } so all that happens when we get a page is balloon_page. and static void balloon_page(void *addr, int deflate) { #if defined(__linux__) if (!qemu_balloon_is_inhibited() && (!kvm_enabled() || kvm_has_sync_mmu())) { qemu_madvise(addr, TARGET_PAGE_SIZE, deflate ? QEMU_MADV_WILLNEED : QEMU_MADV_DONTNEED); } #endif } Do you see anything that tracks pages to help migration skip the balloone...

> 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

> 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

...vq == s->dvq)); > > memory_region_unref(section.mr); > > } > > > > so all that happens when we get a page is balloon_page. > > and > > > > static void balloon_page(void *addr, int deflate) { #if defined(__linux__) > > if (!qemu_balloon_is_inhibited() && (!kvm_enabled() || > > kvm_has_sync_mmu())) { > > qemu_madvise(addr, TARGET_PAGE_SIZE, > > deflate ? QEMU_MADV_WILLNEED : QEMU_MADV_DONTNEED); > > } > > #endif > > } > > >...

...e expectation there? I assume we are saying either poison_val or unmodified? If so I would think the inflate case makes much more sense as that is where the madvise is called that will discard the data. If so it would be pretty easy to just add a check for the poison value to the same spot we check qemu_balloon_is_inhibited. > Let's see if Michael has another opinion. Agreed.

...QEMUBalloonStatus *stat_func, void *opaque); > + QEMUBalloonStatus *stat_func, > + QEMUBalloonFreePages *free_pages_func, > + void *opaque); > void qemu_remove_balloon_handler(void *opaque); > bool qemu_balloon_is_inhibited(void); > void qemu_balloon_inhibit(bool state); > +bool balloon_free_pages_support(void); > +int balloon_get_free_pages(unsigned long *free_pages_bitmap, > + unsigned long *free_pages_count); > > #endif > -- > 1.8.3.1

...ent *event_func, - QEMUBalloonStatus *stat_func, void *opaque); + QEMUBalloonStatus *stat_func, + QEMUBalloonFreePages *free_pages_func, + void *opaque); void qemu_remove_balloon_handler(void *opaque); bool qemu_balloon_is_inhibited(void); void qemu_balloon_inhibit(bool state); +bool balloon_free_pages_support(void); +int balloon_get_free_pages(unsigned long *free_pages_bitmap, + unsigned long *free_pages_count); #endif -- 1.8.3.1

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

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