diff for duplicates of <20151026172216.GC2214@cmpxchg.org> diff --git a/a/1.txt b/N1/1.txt index d6151af..f26fac1 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -42,7 +42,7 @@ But regardless of tcp window control, we need to account socket memory in the main memory accounting pool where pressure is shared (to the best of our abilities) between all accounted memory consumers. -From an interface standpoint alone, I don't think it's reasonable to +>From an interface standpoint alone, I don't think it's reasonable to ask users per default to limit different consumers on a case by case basis. I certainly have no problem with finetuning for scenarios you describe above, but with memory.current, memory.high, memory.max we @@ -56,3 +56,9 @@ exists absolutely wrecks network performance for them. It's not usable the way it is. It'd be much better to have the socket buffers exert pressure on the shared pool, and then propagate the overall pressure back to individual consumers with reclaim, shrinkers, vmpressure etc. + +-- +To unsubscribe, send a message with 'unsubscribe linux-mm' in +the body to majordomo@kvack.org. For more info on Linux MM, +see: http://www.linux-mm.org/ . +Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> diff --git a/a/content_digest b/N1/content_digest index 1c8c9e3..217342d 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,17 +1,17 @@ "ref\01445487696-21545-1-git-send-email-hannes@cmpxchg.org\0" "ref\020151022184509.GM18351@esperanza\0" - "From\0Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>\0" + "From\0Johannes Weiner <hannes@cmpxchg.org>\0" "Subject\0Re: [PATCH 0/8] mm: memcontrol: account socket memory in unified hierarchy\0" "Date\0Mon, 26 Oct 2015 13:22:16 -0400\0" - "To\0Vladimir Davydov <vdavydov-5HdwGun5lf+gSpxsJD1C4w@public.gmane.org>\0" - "Cc\0David S. Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>" - Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> - Michal Hocko <mhocko-AlSwsSmVLrQ@public.gmane.org> - Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> - netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org - linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org - cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org - " linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org\0" + "To\0Vladimir Davydov <vdavydov@virtuozzo.com>\0" + "Cc\0David S. Miller <davem@davemloft.net>" + Andrew Morton <akpm@linux-foundation.org> + Michal Hocko <mhocko@suse.cz> + Tejun Heo <tj@kernel.org> + netdev@vger.kernel.org + linux-mm@kvack.org + cgroups@vger.kernel.org + " linux-kernel@vger.kernel.org\0" "\00:1\0" "b\0" "On Thu, Oct 22, 2015 at 09:45:10PM +0300, Vladimir Davydov wrote:\n" @@ -58,7 +58,7 @@ "in the main memory accounting pool where pressure is shared (to the\n" "best of our abilities) between all accounted memory consumers.\n" "\n" - "From an interface standpoint alone, I don't think it's reasonable to\n" + ">From an interface standpoint alone, I don't think it's reasonable to\n" "ask users per default to limit different consumers on a case by case\n" "basis. I certainly have no problem with finetuning for scenarios you\n" "describe above, but with memory.current, memory.high, memory.max we\n" @@ -71,6 +71,12 @@ "exists absolutely wrecks network performance for them. It's not usable\n" "the way it is. It'd be much better to have the socket buffers exert\n" "pressure on the shared pool, and then propagate the overall pressure\n" - back to individual consumers with reclaim, shrinkers, vmpressure etc. + "back to individual consumers with reclaim, shrinkers, vmpressure etc.\n" + "\n" + "--\n" + "To unsubscribe, send a message with 'unsubscribe linux-mm' in\n" + "the body to majordomo@kvack.org. For more info on Linux MM,\n" + "see: http://www.linux-mm.org/ .\n" + "Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>" -27c66fcdd9ee349bdbf57d560ade2c02fe4d1f4f12b727444fdfbb348997a20c +2c1282f7f074fbc3a80b141314b120383b4c80d8810a2559a9254670b3108936
diff --git a/a/1.txt b/N2/1.txt index d6151af..afae734 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -42,7 +42,7 @@ But regardless of tcp window control, we need to account socket memory in the main memory accounting pool where pressure is shared (to the best of our abilities) between all accounted memory consumers. -From an interface standpoint alone, I don't think it's reasonable to +>From an interface standpoint alone, I don't think it's reasonable to ask users per default to limit different consumers on a case by case basis. I certainly have no problem with finetuning for scenarios you describe above, but with memory.current, memory.high, memory.max we diff --git a/a/content_digest b/N2/content_digest index 1c8c9e3..52756a7 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -1,17 +1,17 @@ "ref\01445487696-21545-1-git-send-email-hannes@cmpxchg.org\0" "ref\020151022184509.GM18351@esperanza\0" - "From\0Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>\0" + "From\0Johannes Weiner <hannes@cmpxchg.org>\0" "Subject\0Re: [PATCH 0/8] mm: memcontrol: account socket memory in unified hierarchy\0" "Date\0Mon, 26 Oct 2015 13:22:16 -0400\0" - "To\0Vladimir Davydov <vdavydov-5HdwGun5lf+gSpxsJD1C4w@public.gmane.org>\0" - "Cc\0David S. Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>" - Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> - Michal Hocko <mhocko-AlSwsSmVLrQ@public.gmane.org> - Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> - netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org - linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org - cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org - " linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org\0" + "To\0Vladimir Davydov <vdavydov@virtuozzo.com>\0" + "Cc\0David S. Miller <davem@davemloft.net>" + Andrew Morton <akpm@linux-foundation.org> + Michal Hocko <mhocko@suse.cz> + Tejun Heo <tj@kernel.org> + netdev@vger.kernel.org + linux-mm@kvack.org + cgroups@vger.kernel.org + " linux-kernel@vger.kernel.org\0" "\00:1\0" "b\0" "On Thu, Oct 22, 2015 at 09:45:10PM +0300, Vladimir Davydov wrote:\n" @@ -58,7 +58,7 @@ "in the main memory accounting pool where pressure is shared (to the\n" "best of our abilities) between all accounted memory consumers.\n" "\n" - "From an interface standpoint alone, I don't think it's reasonable to\n" + ">From an interface standpoint alone, I don't think it's reasonable to\n" "ask users per default to limit different consumers on a case by case\n" "basis. I certainly have no problem with finetuning for scenarios you\n" "describe above, but with memory.current, memory.high, memory.max we\n" @@ -73,4 +73,4 @@ "pressure on the shared pool, and then propagate the overall pressure\n" back to individual consumers with reclaim, shrinkers, vmpressure etc. -27c66fcdd9ee349bdbf57d560ade2c02fe4d1f4f12b727444fdfbb348997a20c +2fcbd288e01ea77e6a18f5ab19bd6f3c3adae8ca7a6df903a42434e980d88f3f
diff --git a/a/1.txt b/N3/1.txt index d6151af..afae734 100644 --- a/a/1.txt +++ b/N3/1.txt @@ -42,7 +42,7 @@ But regardless of tcp window control, we need to account socket memory in the main memory accounting pool where pressure is shared (to the best of our abilities) between all accounted memory consumers. -From an interface standpoint alone, I don't think it's reasonable to +>From an interface standpoint alone, I don't think it's reasonable to ask users per default to limit different consumers on a case by case basis. I certainly have no problem with finetuning for scenarios you describe above, but with memory.current, memory.high, memory.max we diff --git a/a/content_digest b/N3/content_digest index 1c8c9e3..099735e 100644 --- a/a/content_digest +++ b/N3/content_digest @@ -58,7 +58,7 @@ "in the main memory accounting pool where pressure is shared (to the\n" "best of our abilities) between all accounted memory consumers.\n" "\n" - "From an interface standpoint alone, I don't think it's reasonable to\n" + ">From an interface standpoint alone, I don't think it's reasonable to\n" "ask users per default to limit different consumers on a case by case\n" "basis. I certainly have no problem with finetuning for scenarios you\n" "describe above, but with memory.current, memory.high, memory.max we\n" @@ -73,4 +73,4 @@ "pressure on the shared pool, and then propagate the overall pressure\n" back to individual consumers with reclaim, shrinkers, vmpressure etc. -27c66fcdd9ee349bdbf57d560ade2c02fe4d1f4f12b727444fdfbb348997a20c +a9fc494b6ba435cb7a2d5df409976169607be3b0e53e784f58edbad0ebcaaa4f
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.