diff for duplicates of <20200205015057-mutt-send-email-mst@kernel.org> diff --git a/a/1.txt b/N1/1.txt index 6a09a44..af6d583 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,10 +1,10 @@ On Tue, Feb 04, 2020 at 03:58:51PM -0800, Tyler Sanderson wrote: -> >   > -> >   > 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. +> > > +> > > 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. +> > That's *exactly* what "deflate on OOM" suggests. > > > > > > It seems there are some use cases where "deflate on OOM" is desired and @@ -24,7 +24,7 @@ On Tue, Feb 04, 2020 at 03:58:51PM -0800, Tyler Sanderson wrote: > the intended device implementation was. > > I think there are reasonable device implementations that would prefer the -> shrinker behavior (it turns out that mine doesn't). +> shrinker behavior (it turns out that mine doesn't). > For example, an implementation that slowly inflates the balloon for the purpose > of memory overcommit. It might leave the balloon inflated and expect any memory > pressure (including page cache usage) to deflate the balloon as a way to @@ -41,7 +41,7 @@ implementation do? > though it is freeable. This is confusing to users, but isn't a deal breaker. > > If we added a DEFLATE_ON_PRESSURE feature bit that indicated shrinker API -> support then that would resolve reason #1 (ideally we would backport the bit to +> support then that would resolve reason #1 (ideally we would backport the bit to > 4.19). We could declare lack of pagecache pressure with DEFLATE_ON_OOM a @@ -49,11 +49,11 @@ regression and backport the revert but not I think the new DEFLATE_ON_PRESSURE. -> In any case, the shrinker behavior when pressuring page cache is more of an +> In any case, the shrinker behavior when pressuring page cache is more of an > inefficiency than a bug. It's not clear to me that it necessitates reverting. -> If there were/are reasons to be on the shrinker interface then I think those +> If there were/are reasons to be on the shrinker interface then I think those > carry similar weight as the problem itself. ->  +> > > > I consider virtio-balloon to this very day a big hack. And I don't see diff --git a/a/content_digest b/N1/content_digest index ef59335..c5d445a 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -12,21 +12,24 @@ "Subject\0Re: Balloon pressuring page cache\0" "Date\0Wed, 5 Feb 2020 01:57:45 -0500\0" "To\0Tyler Sanderson <tysand@google.com>\0" - "Cc\0virtualization@lists.linux-foundation.org <virtualization@lists.linux-foundation.org>" - linux-mm@kvack.org <linux-mm@kvack.org> - namit@vmware.com - David Rientjes <rientjes@google.com> + "Cc\0David Hildenbrand <david@redhat.com>" Alexander Duyck <alexander.h.duyck@linux.intel.com> - " Michal Hocko <mhocko@kernel.org>\0" + Wang + Wei W <wei.w.wang@intel.com> + virtualization@lists.linux-foundation.org <virtualization@lists.linux-foundation.org> + David Rientjes <rientjes@google.com> + linux-mm@kvack.org <linux-mm@kvack.org> + Michal Hocko <mhocko@kernel.org> + " namit@vmware.com\0" "\00:1\0" "b\0" "On Tue, Feb 04, 2020 at 03:58:51PM -0800, Tyler Sanderson wrote:\n" - "> >\303\202\302\240 \303\202\302\240 \303\202\302\240>\n" - "> >\303\202\302\240 \303\202\302\240 \303\202\302\240>\303\202\302\240 1. It is last-resort, which means the system has already gone through\n" - "> >\303\202\302\240 \303\202\302\240 \303\202\302\240>\303\202\302\240 \303\202\302\240 \303\202\302\240heroics to prevent OOM. Those heroic reclaim efforts are expensive\n" - "> >\303\202\302\240 \303\202\302\240 \303\202\302\240>\303\202\302\240 \303\202\302\240 \303\202\302\240and impact application performance.\n" + "> >\302\240 \302\240 \302\240>\n" + "> >\302\240 \302\240 \302\240>\302\240 1. It is last-resort, which means the system has already gone through\n" + "> >\302\240 \302\240 \302\240>\302\240 \302\240 \302\240heroics to prevent OOM. Those heroic reclaim efforts are expensive\n" + "> >\302\240 \302\240 \302\240>\302\240 \302\240 \302\240and impact application performance.\n" "> >\n" - "> >\303\202\302\240 \303\202\302\240 \303\202\302\240That's *exactly* what \"deflate on OOM\" suggests.\n" + "> >\302\240 \302\240 \302\240That's *exactly* what \"deflate on OOM\" suggests.\n" "> >\n" "> >\n" "> > It seems there are some use cases where \"deflate on OOM\" is desired and\n" @@ -46,7 +49,7 @@ "> the intended device implementation was.\n" "> \n" "> I think there are reasonable device implementations that would prefer the\n" - "> shrinker\303\202\302\240behavior (it turns out that mine doesn't).\n" + "> shrinker\302\240behavior (it turns out that mine doesn't).\n" "> For example, an implementation that slowly inflates the balloon for the purpose\n" "> of memory overcommit. It might leave the balloon inflated and expect any memory\n" "> pressure (including page cache usage) to deflate the balloon as a way to\n" @@ -63,7 +66,7 @@ "> though it is freeable. This is confusing to users, but isn't a deal breaker.\n" "> \n" "> If we added a DEFLATE_ON_PRESSURE feature bit that indicated shrinker API\n" - "> support then that would resolve reason\303\202\302\240#1 (ideally we would backport the bit to\n" + "> support then that would resolve reason\302\240#1 (ideally we would backport the bit to\n" "> 4.19).\n" "\n" "We could declare lack of pagecache pressure with DEFLATE_ON_OOM a\n" @@ -71,11 +74,11 @@ "DEFLATE_ON_PRESSURE.\n" "\n" "\n" - "> In any case, the shrinker\303\202\302\240behavior when pressuring page cache is more of an\n" + "> In any case, the shrinker\302\240behavior when pressuring page cache is more of an\n" "> inefficiency than a bug. It's not clear to me that it necessitates reverting.\n" - "> If there were/are reasons to be on the shrinker\303\202\302\240interface then I think those\n" + "> If there were/are reasons to be on the shrinker\302\240interface then I think those\n" "> carry similar weight as the problem itself.\n" - "> \303\202\302\240\n" + "> \302\240\n" "> \n" "> \n" "> I consider virtio-balloon to this very day a big hack. And I don't see\n" @@ -113,4 +116,4 @@ "> \n" > -eebe9956546c862e1e68a13d8f0b7775efebe567c47a1bd61f0ec57787c3024b +243d892e9ce3642ac28e30033a480f1d85e190b979229f9cbbf1b8bc88016351
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.