diff for duplicates of <FE4CCCF9-CF08-424B-85D0-B5C1BA63329D@linux.dev> diff --git a/a/1.txt b/N1/1.txt index 8ca9811..a50f73c 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -6,7 +6,7 @@ It might make sense in some reasonable range of usages, but if your workload is Thanks! -> On Mar 24, 2022, at 7:33 AM, Chris Down <chris-6Bi1550iOqEnzZ6mRAm98g@public.gmane.org> wrote: +> On Mar 24, 2022, at 7:33 AM, Chris Down <chris@chrisdown.name> wrote: > > I'm confused by the aims of this patch. We already have proportional reclaim for memory.min and memory.low, and memory.high is already "proportional" by its nature to drive memory back down behind the configured threshold. > diff --git a/a/content_digest b/N1/content_digest index 0929371..dd46d99 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,19 +1,18 @@ "ref\0Yjx/3yi7BfH7wLPz@chrisdown.name\0" - "ref\0Yjx/3yi7BfH7wLPz-6Bi1550iOqEnzZ6mRAm98g@public.gmane.org\0" - "From\0Roman Gushchin <roman.gushchin-fxUVXftIFDnyG1zEObXtfA@public.gmane.org>\0" + "From\0Roman Gushchin <roman.gushchin@linux.dev>\0" "Subject\0Re: [RFC PATCH] cgroup: introduce proportional protection on memcg\0" "Date\0Thu, 24 Mar 2022 09:23:44 -0700\0" - "To\0Chris Down <chris-6Bi1550iOqEnzZ6mRAm98g@public.gmane.org>\0" - "Cc\0zhaoyang.huang <zhaoyang.huang-1tVvrHeaX6nQT0dZR+AlfA@public.gmane.org>" - Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> - Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org> - Michal Hocko <mhocko-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> - Vladimir Davydov <vdavydov.dev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> - ke wang <ke.wang-1tVvrHeaX6nQT0dZR+AlfA@public.gmane.org> - Zhaoyang Huang <huangzhaoyang-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> - linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org - linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org - " cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org\0" + "To\0Chris Down <chris@chrisdown.name>\0" + "Cc\0zhaoyang.huang <zhaoyang.huang@unisoc.com>" + Andrew Morton <akpm@linux-foundation.org> + Johannes Weiner <hannes@cmpxchg.org> + Michal Hocko <mhocko@kernel.org> + Vladimir Davydov <vdavydov.dev@gmail.com> + ke wang <ke.wang@unisoc.com> + Zhaoyang Huang <huangzhaoyang@gmail.com> + linux-mm@kvack.org + linux-kernel@vger.kernel.org + " cgroups@vger.kernel.org\0" "\00:1\0" "b\0" "It seems like what\342\200\231s being proposed is an ability to express the protection in % of the current usage rather than an absolute number.\n" @@ -24,11 +23,11 @@ "\n" "Thanks!\n" "\n" - "> On Mar 24, 2022, at 7:33 AM, Chris Down <chris-6Bi1550iOqEnzZ6mRAm98g@public.gmane.org> wrote:\n" + "> On Mar 24, 2022, at 7:33 AM, Chris Down <chris@chrisdown.name> wrote:\n" "> \n" "> \357\273\277I'm confused by the aims of this patch. We already have proportional reclaim for memory.min and memory.low, and memory.high is already \"proportional\" by its nature to drive memory back down behind the configured threshold.\n" "> \n" "> Could you please be more clear about what you're trying to achieve and in what way the existing proportional reclaim mechanisms are insufficient for you?\n" > -618252e228d2bc6ef5b1a6405930465ec282103d84a0cb909034a409738e7d0c +ce42ef7179a009754475a85c1eac53855431daa4c03f73783a8dfa6b5686af12
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.