similar to: [PATCH v4 0/4] vmw_balloon: Compaction and shrinker support

VMware balloon enhancements: adding support for memory compaction, memory shrinker (to prevent OOM) and splitting of refused pages to prevent recurring inflations. Patches 1-2: Support for compaction Patch 3: Support for memory shrinker - disabled by default Patch 4: Split refused pages to improve performance v2->v3: * Fixing wrong argument type (int->size_t) [Michael] * Fixing a comment

On Tue, Apr 23, 2019 at 04:45:28PM -0700, Nadav Amit wrote: > Introduce interfaces for ballooning enqueueing and dequeueing of a list > of pages. These interfaces reduce the overhead of storing and restoring > IRQs by batching the operations. In addition they do not panic if the > list of pages is empty. > > Cc: "Michael S. Tsirkin" <mst at redhat.com> > Cc:

From: Wei Wang <wei.w.wang at intel.com> A #GP is reported in the guest when requesting balloon inflation via virtio-balloon. The reason is that the virtio-balloon driver has removed the page from its internal page list (via balloon_page_pop), but balloon_page_enqueue_one also calls "list_del" to do the removal. This is necessary when it's used from balloon_page_enqueue_list,

From: Wei Wang <wei.w.wang at intel.com> A #GP is reported in the guest when requesting balloon inflation via virtio-balloon. The reason is that the virtio-balloon driver has removed the page from its internal page list (via balloon_page_pop), but balloon_page_enqueue_one also calls "list_del" to do the removal. This is necessary when it's used from balloon_page_enqueue_list,

From: Wei Wang <wei.w.wang at intel.com> A #GP is reported in the guest when requesting balloon inflation via virtio-balloon. The reason is that the virtio-balloon driver has removed the page from its internal page list (via balloon_page_pop), but balloon_page_enqueue_one also calls "list_del" to do the removal. This is necessary when it's used from balloon_page_enqueue_list,

> On May 3, 2019, at 6:25 PM, Nadav Amit <namit at vmware.com> wrote: > >> On Apr 25, 2019, at 4:54 AM, Nadav Amit <namit at vmware.com> wrote: >> >> VMware balloon enhancements: adding support for memory compaction, >> memory shrinker (to prevent OOM) and splitting of refused pages to >> prevent recurring inflations. >> >> Patches

> On May 3, 2019, at 6:25 PM, Nadav Amit <namit at vmware.com> wrote: > >> On Apr 25, 2019, at 4:54 AM, Nadav Amit <namit at vmware.com> wrote: >> >> VMware balloon enhancements: adding support for memory compaction, >> memory shrinker (to prevent OOM) and splitting of refused pages to >> prevent recurring inflations. >> >> Patches

> On May 17, 2019, at 10:24 AM, Greg Kroah-Hartman <gregkh at linuxfoundation.org> wrote: > > On Fri, May 17, 2019 at 05:10:23PM +0000, Nadav Amit wrote: >>> On May 3, 2019, at 6:25 PM, Nadav Amit <namit at vmware.com> wrote: >>> >>>> On Apr 25, 2019, at 4:54 AM, Nadav Amit <namit at vmware.com> wrote: >>>> >>>>

On Thursday, July 18, 2019 8:24 PM, Michael S. Tsirkin wrote: > /* > * balloon_page_alloc - allocates a new page for insertion into the balloon > - * page list. > + * page list. > * > - * Driver must call it to properly allocate a new enlisted balloon page. > - * Driver must call balloon_page_enqueue before definitively removing it > from > - * the guest

On Mon, Dec 28, 2015 at 08:35:13AM +0900, Minchan Kim wrote: > In balloon_page_dequeue, pages_lock should cover the loop > (ie, list_for_each_entry_safe). Otherwise, the cursor page could > be isolated by compaction and then list_del by isolation could > poison the page->lru.{prev,next} so the loop finally could > access wrong address like this. This patch fixes the bug. >

On Mon, Dec 28, 2015 at 08:35:13AM +0900, Minchan Kim wrote: > In balloon_page_dequeue, pages_lock should cover the loop > (ie, list_for_each_entry_safe). Otherwise, the cursor page could > be isolated by compaction and then list_del by isolation could > poison the page->lru.{prev,next} so the loop finally could > access wrong address like this. This patch fixes the bug. >

During my compaction-related stuff, I encountered a bug with ballooning. With repeated inflating and deflating cycle, guest memory( ie, cat /proc/meminfo | grep MemTotal) is decreased and couldn't be recovered. The reason is balloon_lock doesn't cover release_pages_balloon so struct virtio_balloon fields could be overwritten by race of fill_balloon(e,g, vb->*pfns could be critical).

During my compaction-related stuff, I encountered a bug with ballooning. With repeated inflating and deflating cycle, guest memory( ie, cat /proc/meminfo | grep MemTotal) is decreased and couldn't be recovered. The reason is balloon_lock doesn't cover release_pages_balloon so struct virtio_balloon fields could be overwritten by race of fill_balloon(e,g, vb->*pfns could be critical).

On Fri, Jan 08, 2016 at 02:56:14PM -0500, Rafael Aquini wrote: > On Fri, Jan 01, 2016 at 11:36:13AM +0200, Michael S. Tsirkin wrote: > > On Mon, Dec 28, 2015 at 08:35:13AM +0900, Minchan Kim wrote: > > > In balloon_page_dequeue, pages_lock should cover the loop > > > (ie, list_for_each_entry_safe). Otherwise, the cursor page could > > > be isolated by compaction

On Fri, Jan 08, 2016 at 02:56:14PM -0500, Rafael Aquini wrote: > On Fri, Jan 01, 2016 at 11:36:13AM +0200, Michael S. Tsirkin wrote: > > On Mon, Dec 28, 2015 at 08:35:13AM +0900, Minchan Kim wrote: > > > In balloon_page_dequeue, pages_lock should cover the loop > > > (ie, list_for_each_entry_safe). Otherwise, the cursor page could > > > be isolated by compaction

Memory fragmentation introduced by ballooning might reduce significantly the number of 2MB contiguous memory blocks that can be used within a guest, thus imposing performance penalties associated with the reduced number of transparent huge pages that could be used by the guest workload. This patch-set follows the main idea discussed at 2012 LSFMMS session: "Ballooning for transparent huge

Memory fragmentation introduced by ballooning might reduce significantly the number of 2MB contiguous memory blocks that can be used within a guest, thus imposing performance penalties associated with the reduced number of transparent huge pages that could be used by the guest workload. This patch-set follows the main idea discussed at 2012 LSFMMS session: "Ballooning for transparent huge

Memory fragmentation introduced by ballooning might reduce significantly the number of 2MB contiguous memory blocks that can be used within a guest, thus imposing performance penalties associated with the reduced number of transparent huge pages that could be used by the guest workload. This patch-set follows the main idea discussed at 2012 LSFMMS session: "Ballooning for transparent huge

Memory fragmentation introduced by ballooning might reduce significantly the number of 2MB contiguous memory blocks that can be used within a guest, thus imposing performance penalties associated with the reduced number of transparent huge pages that could be used by the guest workload. This patch-set follows the main idea discussed at 2012 LSFMMS session: "Ballooning for transparent huge

On Wed, Dec 02, 2015 at 09:26:34AM -0800, Dmitry Torokhov wrote: > On Wed, Dec 02, 2015 at 07:31:24AM -0800, Greg Kroah-Hartman wrote: > > On Tue, Dec 01, 2015 at 06:21:06PM -0800, Sinclair Yeh wrote: > > > On Tue, Dec 01, 2015 at 04:04:08PM -0800, Greg Kroah-Hartman wrote: > > > > On Tue, Dec 01, 2015 at 02:54:20PM -0800, Sinclair Yeh wrote: > > > > >