From: Michal Hocko <mhocko@kernel.org> To: Johannes Weiner <hannes@cmpxchg.org> Cc: Tejun Heo <tj@kernel.org>, Andrew Morton <akpm@linux-foundation.org>, Roman Gushchin <guro@fb.com>, linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@fb.com Subject: Re: [PATCH v2 3/3] mm: memcontrol: recursive memory.low protection Date: Wed, 26 Feb 2020 18:56:58 +0100 [thread overview] Message-ID: <20200226175658.GP3771@dhcp22.suse.cz> (raw) In-Reply-To: <20200225181755.GB10257@cmpxchg.org> On Tue 25-02-20 13:17:55, Johannes Weiner wrote: > On Tue, Feb 25, 2020 at 01:20:28PM +0100, Michal Hocko wrote: > > > > On Fri 21-02-20 10:43:59, Johannes Weiner wrote: > > > On Fri, Feb 21, 2020 at 11:11:47AM +0100, Michal Hocko wrote: > > [...] > > > > I also have hard time to grasp what you actually mean by the above. > > > > Let's say you have hiearchy where you split out low limit unevenly > > > > root (5G of memory) > > > > / \ > > > > (low 3G) A D (low 1,5G) > > > > / \ > > > > (low 1G) B C (low 2G) > > > > > > > > B gets lower priority than C and D while C gets higher priority than > > > > D? Is there any problem with such a configuration from the semantic > > > > point of view? > > > > > > No, that's completely fine. > > > > How is B (low $EPS) C (low 3-$EPS) where $EPS->0 so much different > > from the above. You prioritize C over B, D over B in both cases under > > global memory pressure. > > You snipped the explanation for the caveat / the priority inversion > that followed; it would be good to reply to that instead. OK, I have misread your response then. Because you were saying that the above example is perfectly fine while it actually matches your example of low, mid, high prio example so I was confused. [...] I am skipping the large part of your response mostly because I believe it would make it easier to move this forward. > > It would be also really appreciated if we have some more specific examples > > of priority inversion problems you have encountered previously and place > > them somewhere into our documentation. There is essentially nothing like > > that in the tree. > > Of course, I wouldn't mind doing that in a separate patch. How about a > section in cgroup-v2.rst, at "Issues with v1 and Rationales for v2"? Yes, makes sense. A subsection about examples/best practices/Lessons learned where we can add more sounds like a very good thing in general. Because regardless of what tends to work for some deployments it is always good to give examples of what hasn't worked for others and was non trivial to find out. This can save countless of hourse for other people. -- Michal Hocko SUSE Labs
WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> To: Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org> Cc: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>, Roman Gushchin <guro-b10kYP2dOMg@public.gmane.org>, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, kernel-team-b10kYP2dOMg@public.gmane.org Subject: Re: [PATCH v2 3/3] mm: memcontrol: recursive memory.low protection Date: Wed, 26 Feb 2020 18:56:58 +0100 [thread overview] Message-ID: <20200226175658.GP3771@dhcp22.suse.cz> (raw) In-Reply-To: <20200225181755.GB10257-druUgvl0LCNAfugRpC6u6w@public.gmane.org> On Tue 25-02-20 13:17:55, Johannes Weiner wrote: > On Tue, Feb 25, 2020 at 01:20:28PM +0100, Michal Hocko wrote: > > > > On Fri 21-02-20 10:43:59, Johannes Weiner wrote: > > > On Fri, Feb 21, 2020 at 11:11:47AM +0100, Michal Hocko wrote: > > [...] > > > > I also have hard time to grasp what you actually mean by the above. > > > > Let's say you have hiearchy where you split out low limit unevenly > > > > root (5G of memory) > > > > / \ > > > > (low 3G) A D (low 1,5G) > > > > / \ > > > > (low 1G) B C (low 2G) > > > > > > > > B gets lower priority than C and D while C gets higher priority than > > > > D? Is there any problem with such a configuration from the semantic > > > > point of view? > > > > > > No, that's completely fine. > > > > How is B (low $EPS) C (low 3-$EPS) where $EPS->0 so much different > > from the above. You prioritize C over B, D over B in both cases under > > global memory pressure. > > You snipped the explanation for the caveat / the priority inversion > that followed; it would be good to reply to that instead. OK, I have misread your response then. Because you were saying that the above example is perfectly fine while it actually matches your example of low, mid, high prio example so I was confused. [...] I am skipping the large part of your response mostly because I believe it would make it easier to move this forward. > > It would be also really appreciated if we have some more specific examples > > of priority inversion problems you have encountered previously and place > > them somewhere into our documentation. There is essentially nothing like > > that in the tree. > > Of course, I wouldn't mind doing that in a separate patch. How about a > section in cgroup-v2.rst, at "Issues with v1 and Rationales for v2"? Yes, makes sense. A subsection about examples/best practices/Lessons learned where we can add more sounds like a very good thing in general. Because regardless of what tends to work for some deployments it is always good to give examples of what hasn't worked for others and was non trivial to find out. This can save countless of hourse for other people. -- Michal Hocko SUSE Labs
next prev parent reply other threads:[~2020-02-26 17:57 UTC|newest] Thread overview: 85+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-12-19 20:07 [PATCH v2 0/3] mm: memcontrol: recursive memory protection Johannes Weiner 2019-12-19 20:07 ` [PATCH v2 1/3] mm: memcontrol: fix memory.low proportional distribution Johannes Weiner 2020-01-30 11:49 ` Michal Hocko 2020-02-03 21:21 ` Johannes Weiner 2020-02-03 21:38 ` Roman Gushchin 2020-02-03 21:38 ` Roman Gushchin 2019-12-19 20:07 ` [PATCH v2 2/3] mm: memcontrol: clean up and document effective low/min calculations Johannes Weiner 2020-01-30 12:54 ` Michal Hocko 2020-02-21 17:10 ` Michal Koutný 2020-02-21 17:10 ` Michal Koutný 2020-02-25 18:40 ` Johannes Weiner 2020-02-25 18:40 ` Johannes Weiner 2020-02-26 16:46 ` Michal Koutný 2020-02-26 19:40 ` Johannes Weiner 2020-02-26 19:40 ` Johannes Weiner 2019-12-19 20:07 ` [PATCH v2 3/3] mm: memcontrol: recursive memory.low protection Johannes Weiner 2020-01-30 17:00 ` Michal Hocko 2020-01-30 17:00 ` Michal Hocko 2020-02-03 21:52 ` Johannes Weiner 2020-02-03 21:52 ` Johannes Weiner 2020-02-10 15:21 ` Johannes Weiner 2020-02-10 15:21 ` Johannes Weiner 2020-02-11 16:47 ` Michal Hocko 2020-02-11 16:47 ` Michal Hocko 2020-02-12 17:08 ` Johannes Weiner 2020-02-12 17:08 ` Johannes Weiner 2020-02-13 7:40 ` Michal Hocko 2020-02-13 7:40 ` Michal Hocko 2020-02-13 13:23 ` Johannes Weiner 2020-02-13 15:46 ` Michal Hocko 2020-02-13 15:46 ` Michal Hocko 2020-02-13 17:41 ` Johannes Weiner 2020-02-13 17:58 ` Johannes Weiner 2020-02-13 17:58 ` Johannes Weiner 2020-02-14 7:59 ` Michal Hocko 2020-02-14 7:59 ` Michal Hocko 2020-02-13 13:53 ` Tejun Heo 2020-02-13 13:53 ` Tejun Heo 2020-02-13 15:47 ` Michal Hocko 2020-02-13 15:52 ` Tejun Heo 2020-02-13 15:52 ` Tejun Heo 2020-02-13 16:36 ` Michal Hocko 2020-02-13 16:36 ` Michal Hocko 2020-02-13 16:57 ` Tejun Heo 2020-02-14 7:15 ` Michal Hocko 2020-02-14 7:15 ` Michal Hocko 2020-02-14 13:57 ` Tejun Heo 2020-02-14 13:57 ` Tejun Heo 2020-02-14 15:13 ` Michal Hocko 2020-02-14 15:13 ` Michal Hocko 2020-02-14 15:40 ` Tejun Heo 2020-02-14 15:40 ` Tejun Heo 2020-02-14 16:53 ` Johannes Weiner 2020-02-14 17:17 ` Tejun Heo 2020-02-17 8:41 ` Michal Hocko 2020-02-17 8:41 ` Michal Hocko 2020-02-18 19:52 ` Johannes Weiner 2020-02-18 19:52 ` Johannes Weiner 2020-02-21 10:11 ` Michal Hocko 2020-02-21 10:11 ` Michal Hocko 2020-02-21 15:43 ` Johannes Weiner 2020-02-21 15:43 ` Johannes Weiner 2020-02-25 12:20 ` Michal Hocko 2020-02-25 18:17 ` Johannes Weiner 2020-02-26 17:56 ` Michal Hocko [this message] 2020-02-26 17:56 ` Michal Hocko 2020-02-21 17:12 ` Michal Koutný 2020-02-21 17:12 ` Michal Koutný 2020-02-21 18:58 ` Johannes Weiner 2020-02-21 18:58 ` Johannes Weiner 2020-02-25 13:37 ` Michal Koutný 2020-02-25 13:37 ` Michal Koutný 2020-02-25 15:03 ` Johannes Weiner 2020-02-25 15:03 ` Johannes Weiner 2020-02-26 13:22 ` Michal Koutný 2020-02-26 13:22 ` Michal Koutný 2020-02-26 15:05 ` Johannes Weiner 2020-02-26 15:05 ` Johannes Weiner 2020-02-27 13:35 ` Michal Koutný 2020-02-27 13:35 ` Michal Koutný 2020-02-27 15:06 ` Johannes Weiner 2020-02-27 15:06 ` Johannes Weiner 2019-12-19 20:22 ` [PATCH v2 0/3] mm: memcontrol: recursive memory protection Tejun Heo 2019-12-20 4:06 ` Roman Gushchin 2019-12-20 4:29 ` Chris Down
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200226175658.GP3771@dhcp22.suse.cz \ --to=mhocko@kernel.org \ --cc=akpm@linux-foundation.org \ --cc=cgroups@vger.kernel.org \ --cc=guro@fb.com \ --cc=hannes@cmpxchg.org \ --cc=kernel-team@fb.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=tj@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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.