similar to: [PATCH RESEND] mm: don't zero ballooned pages

Ballooned pages will be marked as MADV_DONTNEED by the hypervisor and shouldn't be given to the host ksmd to scan. Therefore, it is not necessary to zero ballooned pages, which is very time consuming when the page amount is large. The ongoing fast balloon tests show that the time to balloon 7G pages is increased from ~491ms to 2.8 seconds with __GFP_ZERO added. So, this patch removes the flag.

Ballooned pages will be marked as MADV_DONTNEED by the hypervisor and shouldn't be given to the host ksmd to scan. Therefore, it is not necessary to zero ballooned pages, which is very time consuming when the page amount is large. The ongoing fast balloon tests show that the time to balloon 7G pages is increased from ~491ms to 2.8 seconds with __GFP_ZERO added. So, this patch removes the flag.

On 07/31/2017 02:55 PM, Michal Hocko wrote: > On Mon 31-07-17 12:13:33, Wei Wang wrote: >> Ballooned pages will be marked as MADV_DONTNEED by the hypervisor and >> shouldn't be given to the host ksmd to scan. > Could you point me where this MADV_DONTNEED is done, please? Sure. It's done in the hypervisor when the balloon pages are received. Please see line 40 at

On 07/31/2017 02:55 PM, Michal Hocko wrote: > On Mon 31-07-17 12:13:33, Wei Wang wrote: >> Ballooned pages will be marked as MADV_DONTNEED by the hypervisor and >> shouldn't be given to the host ksmd to scan. > Could you point me where this MADV_DONTNEED is done, please? Sure. It's done in the hypervisor when the balloon pages are received. Please see line 40 at

On Thu 03-08-17 19:59:17, Wei Wang wrote: > This patch is a revert of 'commit bb01b64cfab7 ("mm/balloon_compaction.c: > enqueue zero page to balloon device")' > > Ballooned pages will be marked as MADV_DONTNEED by the hypervisor and > shouldn't be given to the host ksmd to scan. I find MADV_DONTNEED reference still quite confusing. What do you think about the

On Mon 07-08-17 10:44:50, David Hildenbrand wrote: > On 03.08.2017 13:59, Wei Wang wrote: > > This patch is a revert of 'commit bb01b64cfab7 ("mm/balloon_compaction.c: > > enqueue zero page to balloon device")' > > > > Ballooned pages will be marked as MADV_DONTNEED by the hypervisor and > > shouldn't be given to the host ksmd to scan.

On Mon 07-08-17 10:44:50, David Hildenbrand wrote: > On 03.08.2017 13:59, Wei Wang wrote: > > This patch is a revert of 'commit bb01b64cfab7 ("mm/balloon_compaction.c: > > enqueue zero page to balloon device")' > > > > Ballooned pages will be marked as MADV_DONTNEED by the hypervisor and > > shouldn't be given to the host ksmd to scan.

On 03.08.2017 13:59, Wei Wang wrote: > This patch is a revert of 'commit bb01b64cfab7 ("mm/balloon_compaction.c: > enqueue zero page to balloon device")' > > Ballooned pages will be marked as MADV_DONTNEED by the hypervisor and > shouldn't be given to the host ksmd to scan. Therefore, it is not > necessary to zero ballooned pages, which is very time

On Mon 31-07-17 12:13:33, Wei Wang wrote: > Ballooned pages will be marked as MADV_DONTNEED by the hypervisor and > shouldn't be given to the host ksmd to scan. Could you point me where this MADV_DONTNEED is done, please? > Therefore, it is not > necessary to zero ballooned pages, which is very time consuming when > the page amount is large. The ongoing fast balloon tests show

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

On Mon 31-07-17 16:23:26, ZhenweiPi wrote: > On 07/31/2017 03:51 PM, Michal Hocko wrote: > > >On Mon 31-07-17 15:41:49, Wei Wang wrote: > >>>On 07/31/2017 02:55 PM, Michal Hocko wrote: > >>>> >On Mon 31-07-17 12:13:33, Wei Wang wrote: > >>>>> >>Ballooned pages will be marked as MADV_DONTNEED by the hypervisor and >

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

On Mon 31-07-17 15:41:49, Wei Wang wrote: > On 07/31/2017 02:55 PM, Michal Hocko wrote: > >On Mon 31-07-17 12:13:33, Wei Wang wrote: > >>Ballooned pages will be marked as MADV_DONTNEED by the hypervisor and > >>shouldn't be given to the host ksmd to scan. > >Could you point me where this MADV_DONTNEED is done, please? > > Sure. It's done in the

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

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 v3->v4: * "get around to" comment [Michael] * Put list_add under page lock

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 v3->v4: * "get around to" comment [Michael] * Put list_add under page lock

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