similar to: How to get a sense of VM pressure

On Tue, Feb 4, 2020 at 11:17 AM David Hildenbrand <david at redhat.com> wrote: > On 04.02.20 19:52, Tyler Sanderson wrote: > > > > > > On Tue, Feb 4, 2020 at 12:29 AM David Hildenbrand <david at redhat.com > > <mailto:david at redhat.com>> wrote: > > > > On 03.02.20 21:32, Tyler Sanderson wrote: > > > There were apparently

On Tue, Feb 4, 2020 at 11:17 AM David Hildenbrand <david at redhat.com> wrote: > On 04.02.20 19:52, Tyler Sanderson wrote: > > > > > > On Tue, Feb 4, 2020 at 12:29 AM David Hildenbrand <david at redhat.com > > <mailto:david at redhat.com>> wrote: > > > > On 03.02.20 21:32, Tyler Sanderson wrote: > > > There were apparently

There are cases that users want to shrink balloon pages after the pagecache depleted. The conservative_shrinker lets the shrinker shrink balloon pages when all the pagecache has been reclaimed. Signed-off-by: Wei Wang <wei.w.wang at intel.com> --- drivers/virtio/virtio_balloon.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git

There are cases that users want to shrink balloon pages after the pagecache depleted. The conservative_shrinker lets the shrinker shrink balloon pages when all the pagecache has been reclaimed. Signed-off-by: Wei Wang <wei.w.wang at intel.com> --- drivers/virtio/virtio_balloon.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git

On Saturday, February 8, 2020 8:33 PM, Tetsuo Handa wrote: > > Is this NUMA aware? Can "node-A's NR_FILE_PAGES is already 0 and > node-B's NR_FILE_PAGES is not 0, but allocation request which triggered this > shrinker wants to allocate from only node-B" happen? No, it's a global counter. >Can some thread keep > this shrinker defunctional by keep

On Saturday, February 8, 2020 8:33 PM, Tetsuo Handa wrote: > > Is this NUMA aware? Can "node-A's NR_FILE_PAGES is already 0 and > node-B's NR_FILE_PAGES is not 0, but allocation request which triggered this > shrinker wants to allocate from only node-B" happen? No, it's a global counter. >Can some thread keep > this shrinker defunctional by keep

On Monday, February 10, 2020 11:57 AM, Tetsuo Handa wrote: > Then, "node-A's NR_FILE_PAGES is already 0 and node-B's NR_FILE_PAGES is > not 0, but allocation request which triggered this shrinker wants to allocate > from only node-A" > would be confused by this change, for the pagecache pages for allocating > thread's interested node are already depleted but

On Monday, February 10, 2020 11:57 AM, Tetsuo Handa wrote: > Then, "node-A's NR_FILE_PAGES is already 0 and node-B's NR_FILE_PAGES is > not 0, but allocation request which triggered this shrinker wants to allocate > from only node-A" > would be confused by this change, for the pagecache pages for allocating > thread's interested node are already depleted but

On Fri, Oct 04, 2019 at 10:06:03AM +0200, David Hildenbrand wrote: > On 04.10.19 01:15, Tyler Sanderson wrote: > > I was mistaken, the problem with overcommit accounting is not fixed by > > the change to shrinker interface. > > This means that large allocations are stopped even if they could succeed > > by deflating the balloon. > > Please note that some people

On Fri, Oct 04, 2019 at 10:06:03AM +0200, David Hildenbrand wrote: > On 04.10.19 01:15, Tyler Sanderson wrote: > > I was mistaken, the problem with overcommit accounting is not fixed by > > the change to shrinker interface. > > This means that large allocations are stopped even if they could succeed > > by deflating the balloon. > > Please note that some people

On 03.02.20 17:18, Alexander Duyck wrote: > On Mon, 2020-02-03 at 08:11 -0500, Michael S. Tsirkin wrote: >> On Thu, Jan 30, 2020 at 11:59:46AM -0800, Tyler Sanderson wrote: >>> >>> On Thu, Jan 30, 2020 at 7:31 AM Wang, Wei W <wei.w.wang at intel.com> wrote: >>> >>> On Thursday, January 30, 2020 11:03 PM, David Hildenbrand wrote: >>>

On 03.02.20 17:18, Alexander Duyck wrote: > On Mon, 2020-02-03 at 08:11 -0500, Michael S. Tsirkin wrote: >> On Thu, Jan 30, 2020 at 11:59:46AM -0800, Tyler Sanderson wrote: >>> >>> On Thu, Jan 30, 2020 at 7:31 AM Wang, Wei W <wei.w.wang at intel.com> wrote: >>> >>> On Thursday, January 30, 2020 11:03 PM, David Hildenbrand wrote: >>>

> On Feb 3, 2020, at 2:50 PM, Nadav Amit <namit at vmware.com> wrote: > >> On Feb 3, 2020, at 8:34 AM, David Hildenbrand <david at redhat.com> wrote: >> >> On 03.02.20 17:18, Alexander Duyck wrote: >>> On Mon, 2020-02-03 at 08:11 -0500, Michael S. Tsirkin wrote: >>>> On Thu, Jan 30, 2020 at 11:59:46AM -0800, Tyler Sanderson wrote:

> On Feb 3, 2020, at 2:50 PM, Nadav Amit <namit at vmware.com> wrote: > >> On Feb 3, 2020, at 8:34 AM, David Hildenbrand <david at redhat.com> wrote: >> >> On 03.02.20 17:18, Alexander Duyck wrote: >>> On Mon, 2020-02-03 at 08:11 -0500, Michael S. Tsirkin wrote: >>>> On Thu, Jan 30, 2020 at 11:59:46AM -0800, Tyler Sanderson wrote:

Two fixes for issues I stumbled over while working on patch #3. Switch back to the good ol' OOM handler for VIRTIO_BALLOON_F_DEFLATE_ON_OOM as the switch to the shrinker introduce some undesired side effects. Keep the shrinker in place to handle VIRTIO_BALLOON_F_FREE_PAGE_HINT. Lengthy discussion under [1]. I tested with QEMU and "deflate-on-oom=on". Works as expected. Did not test

There were apparently good reasons for moving away from OOM notifier callback: https://lkml.org/lkml/2018/7/12/314 https://lkml.org/lkml/2018/8/2/322 In particular the OOM notifier is worse than the shrinker because: 1. It is last-resort, which means the system has already gone through heroics to prevent OOM. Those heroic reclaim efforts are expensive and impact application performance.

There were apparently good reasons for moving away from OOM notifier callback: https://lkml.org/lkml/2018/7/12/314 https://lkml.org/lkml/2018/8/2/322 In particular the OOM notifier is worse than the shrinker because: 1. It is last-resort, which means the system has already gone through heroics to prevent OOM. Those heroic reclaim efforts are expensive and impact application performance.

On Wed, Feb 05, 2020 at 09:19:58AM +0100, David Hildenbrand wrote: > On 05.02.20 08:35, Nadav Amit wrote: > >> On Feb 3, 2020, at 2:50 PM, Nadav Amit <namit at vmware.com> wrote: > >> > >>> On Feb 3, 2020, at 8:34 AM, David Hildenbrand <david at redhat.com> wrote: > >>> > >>> On 03.02.20 17:18, Alexander Duyck wrote: >

On Wed, Feb 5, 2020 at 8:34 AM David Hildenbrand <david at redhat.com> wrote: > Commit 71994620bb25 ("virtio_balloon: replace oom notifier with shrinker") > changed the behavior when deflation happens automatically. Instead of > deflating when called by the OOM handler, the shrinker is used. > > However, the balloon is not simply some slab cache that should be >

On Wed, Feb 5, 2020 at 8:34 AM David Hildenbrand <david at redhat.com> wrote: > Commit 71994620bb25 ("virtio_balloon: replace oom notifier with shrinker") > changed the behavior when deflation happens automatically. Instead of > deflating when called by the OOM handler, the shrinker is used. > > However, the balloon is not simply some slab cache that should be >