From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.3 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 79620C35247 for ; Tue, 4 Feb 2020 18:52:56 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2994A2082E for ; Tue, 4 Feb 2020 18:52:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="i0vDtfwJ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2994A2082E Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A46C46B0003; Tue, 4 Feb 2020 13:52:55 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9D0556B0005; Tue, 4 Feb 2020 13:52:55 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 897806B0007; Tue, 4 Feb 2020 13:52:55 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0069.hostedemail.com [216.40.44.69]) by kanga.kvack.org (Postfix) with ESMTP id 6CFA46B0003 for ; Tue, 4 Feb 2020 13:52:55 -0500 (EST) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 1236A180AD802 for ; Tue, 4 Feb 2020 18:52:55 +0000 (UTC) X-FDA: 76453341510.25.rate10_3687442feaf0a X-HE-Tag: rate10_3687442feaf0a X-Filterd-Recvd-Size: 9076 Received: from mail-vs1-f53.google.com (mail-vs1-f53.google.com [209.85.217.53]) by imf28.hostedemail.com (Postfix) with ESMTP for ; Tue, 4 Feb 2020 18:52:54 +0000 (UTC) Received: by mail-vs1-f53.google.com with SMTP id v141so12024139vsv.12 for ; Tue, 04 Feb 2020 10:52:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JFjuhlOU48p12QMv00/QPBxxPW3d/P9IoYypv065CfE=; b=i0vDtfwJSIMb0pbgmz469WvBT6h3lntoMPaoC19R21ozGQl0RIcwGd9Ce+H7blpc/6 RHOZr6xpSMSW83IW/n08oOe2mZHC+qnj0tWf3xMnsrVHXBcL7dNERaei2cqUDHbcbiCd 19tzLkVR2qriGBu0i3AD3R7MxIXFqhtPeZfD0GfQ1OJ0TVEc9UBKUy7RSKmh0Bpml0ae 38xyA9qNFsfhHqj8CxDV7aNgMas4OG/bZMOYB1zaxHIjedf5jBjBIK6HhKU35YDRId8x b4997f0M9Os3+EHBzuz5gJYvH4rP5DsBXEp9lgXoCansHnUEW6dSitpE3xKWElZXo2iq 48zQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JFjuhlOU48p12QMv00/QPBxxPW3d/P9IoYypv065CfE=; b=aYAVcWv9LWftjKltBc6MzYJMb0hhfHoAzb3mWau4TIlY/aO9PVeQdCBAs4UZQ5rIjo eQF0sc4+EtNM5f5EK+naNILwtfIPJovIZEdTiCKAGeKLZD8BP8EQPQjhKJkMHTu4Huw0 PymVR2pNtKAC9t4E0Vla29LJ3+X2DIJjdB4B2damUsayqOp/Im6qdcKS5yItM2L9tvt4 4cBEvryel3FwtdnROQvdDRIpUhaGtD5h2ZlOVUN8I1J7vlYNAxFYphoKkwZklvk4wIOh 9ASfnKnJ87u+HLzBOKHfA0bjPOC3EFuO5fNRIiXMfOpgO8pMFYFwdVDajhiJaZzuhoCc zApQ== X-Gm-Message-State: APjAAAVWyrb2MZPzWtCCJrdVxhXOomGMRaJLxRARiD2qHwlqkeHh0dQ4 GzDQNvNZH99EnU6u/CtlRKZI/t7ttsvzi5MygQWkCg== X-Google-Smtp-Source: APXvYqxPOffbTHs6dP9CmwCbqDZvA029uMmiJaVYrG/dhOyMzIxue5TSSUCy/LAEA7ZbPpQiwn6P80yKmAjXW6XzIJM= X-Received: by 2002:a05:6102:72b:: with SMTP id u11mr19360198vsg.69.1580842373898; Tue, 04 Feb 2020 10:52:53 -0800 (PST) MIME-Version: 1.0 References: <91270a68-ff48-88b0-219c-69801f0c252f@redhat.com> <75d4594f-0864-5172-a0f8-f97affedb366@redhat.com> <286AC319A985734F985F78AFA26841F73E3F8A02@shsmsx102.ccr.corp.intel.com> <20200203080520-mutt-send-email-mst@kernel.org> <5ac131de8e3b7fc1fafd05a61feb5f6889aeb917.camel@linux.intel.com> <20200203120225-mutt-send-email-mst@kernel.org> <74cc25a6-cefb-c580-8e59-5b76fb680bf4@redhat.com> In-Reply-To: <74cc25a6-cefb-c580-8e59-5b76fb680bf4@redhat.com> From: Tyler Sanderson Date: Tue, 4 Feb 2020 10:52:42 -0800 Message-ID: Subject: Re: Balloon pressuring page cache To: David Hildenbrand Cc: "Michael S. Tsirkin" , Alexander Duyck , "Wang, Wei W" , "virtualization@lists.linux-foundation.org" , David Rientjes , "linux-mm@kvack.org" , Michal Hocko , namit@vmware.com Content-Type: multipart/alternative; boundary="00000000000024c073059dc48c52" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: --00000000000024c073059dc48c52 Content-Type: text/plain; charset="UTF-8" On Tue, Feb 4, 2020 at 12:29 AM David Hildenbrand wrote: > On 03.02.20 21:32, Tyler Sanderson wrote: > > 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: > > The issue is that DEFLATE_ON_OOM is under-specified. > > > > > 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. > > That's *exactly* what "deflate on OOM" suggests. > It seems there are some use cases where "deflate on OOM" is desired and others where "deflate on pressure" is desired. This suggests adding a new feature bit "DEFLATE_ON_PRESSURE" that registers the shrinker, and reverting DEFLATE_ON_OOM to use the OOM notifier callback. This lets users configure the balloon for their use case. > > Assume you are using virtio-balloon for some weird way of memory > hotunplug (which is what some people do) and you want to minimize the > footprint of your guest. Then you really only want to give the guest > more memory (or rather, let it take back memory automatically in this > case) in case it really needs more memory. It should try to reclaim first. > > Under-specified. > > > > 2. It lacks understanding of NUMA or other OOM constraints. > > Ballooning in general lacks the understanding of NUMA. > > > 3. It has a higher potential for bugs due to the subtlety of the > > callback context. > > While that is a valid point, it doesn't explain why existing > functionality is changed. > > Personally, I think DEFLATE_ON_OOM should never have been introduced (at > least not in this form). > I'm actually not sure how you would safely do memory overcommit without DEFLATE_ON_OOM. So I think it unlocks a huge use case. > > > -- > Thanks, > > David / dhildenb > > --00000000000024c073059dc48c52 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Feb 4, 2020 at 12:29 AM David= Hildenbrand <david@redhat.com&g= t; wrote:
On 03.= 02.20 21:32, Tyler Sanderson wrote:
> 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:

The issue is that DEFLATE_ON_OOM is under-specified.

>
>=C2=A0 1. It is last-resort, which means the system has already gone th= rough
>=C2=A0 =C2=A0 =C2=A0heroics to prevent OOM. Those heroic reclaim effort= s are expensive
>=C2=A0 =C2=A0 =C2=A0and impact application performance.

That's *exactly* what "deflate on OOM" suggests.

It seems there are some use cases where "defla= te on OOM" is desired and others where "deflate on pressure"= is desired.
This suggests adding a new feature bit "DEFLATE= _ON_PRESSURE" that registers the shrinker, and reverting DEFLATE_ON_OO= M to use the OOM notifier callback.

This lets user= s configure the balloon for their use case.
=C2=A0

Assume you are using virtio-balloon for some weird way of memory
hotunplug (which is what some people do) and you want to minimize the
footprint of your guest. Then you really only want to give the guest
more memory (or rather, let it take back memory automatically in this
case) in case it really needs more memory. It should try to reclaim first.<= br>
Under-specified.


>=C2=A0 2. It lacks understanding of NUMA or other OOM constraints.

Ballooning in general lacks the understanding of NUMA.

>=C2=A0 3. It has a higher potential for bugs due to the subtlety=C2=A0o= f the
>=C2=A0 =C2=A0 =C2=A0callback context.

While that is a valid point, it doesn't explain why existing
functionality is changed.

Personally, I think DEFLATE_ON_OOM should never have been introduced (at least not in this form).
I'm actually not sure how= you would safely do memory overcommit without DEFLATE_ON_OOM. So I think i= t unlocks a huge use case.
=C2=A0


--
Thanks,

David / dhildenb

--00000000000024c073059dc48c52-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tyler Sanderson via Virtualization Subject: Re: Balloon pressuring page cache Date: Tue, 4 Feb 2020 10:52:42 -0800 Message-ID: References: <91270a68-ff48-88b0-219c-69801f0c252f@redhat.com> <75d4594f-0864-5172-a0f8-f97affedb366@redhat.com> <286AC319A985734F985F78AFA26841F73E3F8A02@shsmsx102.ccr.corp.intel.com> <20200203080520-mutt-send-email-mst@kernel.org> <5ac131de8e3b7fc1fafd05a61feb5f6889aeb917.camel@linux.intel.com> <20200203120225-mutt-send-email-mst@kernel.org> <74cc25a6-cefb-c580-8e59-5b76fb680bf4@redhat.com> Reply-To: Tyler Sanderson Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3259729004362866944==" Return-path: In-Reply-To: <74cc25a6-cefb-c580-8e59-5b76fb680bf4@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: virtualization-bounces@lists.linux-foundation.org Sender: "Virtualization" To: David Hildenbrand Cc: "Michael S. Tsirkin" , "virtualization@lists.linux-foundation.org" , "linux-mm@kvack.org" , namit@vmware.com, David Rientjes , Alexander Duyck , Michal Hocko List-Id: virtualization@lists.linuxfoundation.org --===============3259729004362866944== Content-Type: multipart/alternative; boundary="00000000000024c073059dc48c52" --00000000000024c073059dc48c52 Content-Type: text/plain; charset="UTF-8" On Tue, Feb 4, 2020 at 12:29 AM David Hildenbrand wrote: > On 03.02.20 21:32, Tyler Sanderson wrote: > > 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: > > The issue is that DEFLATE_ON_OOM is under-specified. > > > > > 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. > > That's *exactly* what "deflate on OOM" suggests. > It seems there are some use cases where "deflate on OOM" is desired and others where "deflate on pressure" is desired. This suggests adding a new feature bit "DEFLATE_ON_PRESSURE" that registers the shrinker, and reverting DEFLATE_ON_OOM to use the OOM notifier callback. This lets users configure the balloon for their use case. > > Assume you are using virtio-balloon for some weird way of memory > hotunplug (which is what some people do) and you want to minimize the > footprint of your guest. Then you really only want to give the guest > more memory (or rather, let it take back memory automatically in this > case) in case it really needs more memory. It should try to reclaim first. > > Under-specified. > > > > 2. It lacks understanding of NUMA or other OOM constraints. > > Ballooning in general lacks the understanding of NUMA. > > > 3. It has a higher potential for bugs due to the subtlety of the > > callback context. > > While that is a valid point, it doesn't explain why existing > functionality is changed. > > Personally, I think DEFLATE_ON_OOM should never have been introduced (at > least not in this form). > I'm actually not sure how you would safely do memory overcommit without DEFLATE_ON_OOM. So I think it unlocks a huge use case. > > > -- > Thanks, > > David / dhildenb > > --00000000000024c073059dc48c52 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Feb 4, 2020 at 12:29 AM David= Hildenbrand <david@redhat.com&g= t; wrote:
On 03.= 02.20 21:32, Tyler Sanderson wrote:
> 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:

The issue is that DEFLATE_ON_OOM is under-specified.

>
>=C2=A0 1. It is last-resort, which means the system has already gone th= rough
>=C2=A0 =C2=A0 =C2=A0heroics to prevent OOM. Those heroic reclaim effort= s are expensive
>=C2=A0 =C2=A0 =C2=A0and impact application performance.

That's *exactly* what "deflate on OOM" suggests.

It seems there are some use cases where "defla= te on OOM" is desired and others where "deflate on pressure"= is desired.
This suggests adding a new feature bit "DEFLATE= _ON_PRESSURE" that registers the shrinker, and reverting DEFLATE_ON_OO= M to use the OOM notifier callback.

This lets user= s configure the balloon for their use case.
=C2=A0

Assume you are using virtio-balloon for some weird way of memory
hotunplug (which is what some people do) and you want to minimize the
footprint of your guest. Then you really only want to give the guest
more memory (or rather, let it take back memory automatically in this
case) in case it really needs more memory. It should try to reclaim first.<= br>
Under-specified.


>=C2=A0 2. It lacks understanding of NUMA or other OOM constraints.

Ballooning in general lacks the understanding of NUMA.

>=C2=A0 3. It has a higher potential for bugs due to the subtlety=C2=A0o= f the
>=C2=A0 =C2=A0 =C2=A0callback context.

While that is a valid point, it doesn't explain why existing
functionality is changed.

Personally, I think DEFLATE_ON_OOM should never have been introduced (at least not in this form).
I'm actually not sure how= you would safely do memory overcommit without DEFLATE_ON_OOM. So I think i= t unlocks a huge use case.
=C2=A0


--
Thanks,

David / dhildenb

--00000000000024c073059dc48c52-- --===============3259729004362866944== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization --===============3259729004362866944==--