similar to: [PATCH RFC 0/1] virtio-balloon vs. endianness

As virtio-1 devices use little endian on their queues, we need to make sure the pfns are in virtio32 format before we put them on the queue. Signed-off-by: Cornelia Huck <cornelia.huck at de.ibm.com> --- drivers/virtio/virtio_balloon.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c index

Everything should be LE when using virtio-1, but the linux balloon driver does not seem to care about that. Cc: stable at vger.kernel.org Reported-by: Cornelia Huck <cornelia.huck at de.ibm.com> Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/virtio/virtio_balloon.c | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) diff --git

Everything should be LE when using virtio-1, but the linux balloon driver does not seem to care about that. Cc: stable at vger.kernel.org Reported-by: Cornelia Huck <cornelia.huck at de.ibm.com> Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/virtio/virtio_balloon.c | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) diff --git

This patch series intends to summarize the recent contributions made by Michael S. Tsirkin, Tetsuo Handa, Michal Hocko etc. via reporting and discussing the related deadlock issues on the mailinglist. Please check each patch for details. >From a high-level point of view, this patch series achieves: 1) eliminate the deadlock issue fundamentally caused by the inability to run leak_balloon and

This patch series intends to summarize the recent contributions made by Michael S. Tsirkin, Tetsuo Handa, Michal Hocko etc. via reporting and discussing the related deadlock issues on the mailinglist. Please check each patch for details. >From a high-level point of view, this patch series achieves: 1) eliminate the deadlock issue fundamentally caused by the inability to run leak_balloon and

Wei Wang wrote: > The balloon_lock was used to synchronize the access demand to elements > of struct virtio_balloon and its queue operations (please see commit > e22504296d). This prevents the concurrent run of the leak_balloon and > fill_balloon functions, thereby resulting in a deadlock issue on OOM: > > fill_balloon: take balloon_lock and wait for OOM to get some memory; >

Wei Wang wrote: > The balloon_lock was used to synchronize the access demand to elements > of struct virtio_balloon and its queue operations (please see commit > e22504296d). This prevents the concurrent run of the leak_balloon and > fill_balloon functions, thereby resulting in a deadlock issue on OOM: > > fill_balloon: take balloon_lock and wait for OOM to get some memory; >

fill_balloon doing memory allocations under balloon_lock can cause a deadlock when leak_balloon is called from virtballoon_oom_notify and tries to take same lock. To fix, split page allocation and enqueue and do allocations outside the lock. Here's a detailed analysis of the deadlock by Tetsuo Handa: In leak_balloon(), mutex_lock(&vb->balloon_lock) is called in order to serialize

fill_balloon doing memory allocations under balloon_lock can cause a deadlock when leak_balloon is called from virtballoon_oom_notify and tries to take same lock. To fix, split page allocation and enqueue and do allocations outside the lock. Here's a detailed analysis of the deadlock by Tetsuo Handa: In leak_balloon(), mutex_lock(&vb->balloon_lock) is called in order to serialize

The implementation of the current virtio-balloon is not very efficient, Bellow is test result of time spends on inflating the balloon to 3GB of a 4GB idle guest: a. allocating pages (6.5%, 103ms) b. sending PFNs to host (68.3%, 787ms) c. address translation (6.1%, 96ms) d. madvise (19%, 300ms) It takes about 1577ms for the whole inflating process to complete. The test shows that the bottle neck

The implementation of the current virtio-balloon is not very efficient, Bellow is test result of time spends on inflating the balloon to 3GB of a 4GB idle guest: a. allocating pages (6.5%, 103ms) b. sending PFNs to host (68.3%, 787ms) c. address translation (6.1%, 96ms) d. madvise (19%, 300ms) It takes about 1577ms for the whole inflating process to complete. The test shows that the bottle neck

Wei Wang wrote: > >> @@ -162,20 +160,20 @@ static unsigned fill_balloon(struct virtio_balloon *vb, size_t num) > >> msleep(200); > >> break; > >> } > >> - set_page_pfns(vb, vb->pfns + vb->num_pfns, page); > >> - vb->num_pages += VIRTIO_BALLOON_PAGES_PER_PAGE; > >> + set_page_pfns(vb, pfns + num_pfns, page);

Wei Wang wrote: > >> @@ -162,20 +160,20 @@ static unsigned fill_balloon(struct virtio_balloon *vb, size_t num) > >> msleep(200); > >> break; > >> } > >> - set_page_pfns(vb, vb->pfns + vb->num_pfns, page); > >> - vb->num_pages += VIRTIO_BALLOON_PAGES_PER_PAGE; > >> + set_page_pfns(vb, pfns + num_pfns, page);

> On Fri, May 20, 2016 at 05:59:46PM +0800, Liang Li wrote: > > The implementation of the current virtio-balloon is not very > > efficient, Bellow is test result of time spends on inflating the > > balloon to 3GB of a 4GB idle guest: > > > > a. allocating pages (6.5%, 103ms) > > b. sending PFNs to host (68.3%, 787ms) c. address translation (6.1%, > >

> On Fri, May 20, 2016 at 05:59:46PM +0800, Liang Li wrote: > > The implementation of the current virtio-balloon is not very > > efficient, Bellow is test result of time spends on inflating the > > balloon to 3GB of a 4GB idle guest: > > > > a. allocating pages (6.5%, 103ms) > > b. sending PFNs to host (68.3%, 787ms) c. address translation (6.1%, > >

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

This patch series implements two optimizations: 1) transfer pages in chuncks between the guest and host; 2) transfer the guest unused pages to the host so that they can be skipped to migrate in live migration. Changes: v8->v9: 1) Split the two new features, VIRTIO_BALLOON_F_BALLOON_CHUNKS and VIRTIO_BALLOON_F_MISC_VQ, which were mixed together in the previous implementation; 2) Simpler

This patch series implements two optimizations: 1) transfer pages in chuncks between the guest and host; 2) transfer the guest unused pages to the host so that they can be skipped to migrate in live migration. Changes: v8->v9: 1) Split the two new features, VIRTIO_BALLOON_F_BALLOON_CHUNKS and VIRTIO_BALLOON_F_MISC_VQ, which were mixed together in the previous implementation; 2) Simpler

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