From: Roman Gushchin <guro@fb.com> To: Michal Hocko <mhocko@kernel.org> Cc: David Rientjes <rientjes@google.com>, <linux-mm@kvack.org>, Vladimir Davydov <vdavydov.dev@gmail.com>, Johannes Weiner <hannes@cmpxchg.org>, Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>, Andrew Morton <akpm@linux-foundation.org>, Tejun Heo <tj@kernel.org>, <kernel-team@fb.com>, <cgroups@vger.kernel.org>, <linux-doc@vger.kernel.org>, <linux-kernel@vger.kernel.org> Subject: Re: [v8 0/4] cgroup-aware OOM killer Date: Fri, 15 Sep 2017 08:23:01 -0700 [thread overview] Message-ID: <20170915152301.GA29379@castle> (raw) In-Reply-To: <20170915105826.hq5afcu2ij7hevb4@dhcp22.suse.cz> On Fri, Sep 15, 2017 at 12:58:26PM +0200, Michal Hocko wrote: > On Thu 14-09-17 09:05:48, Roman Gushchin wrote: > > On Thu, Sep 14, 2017 at 03:40:14PM +0200, Michal Hocko wrote: > > > On Wed 13-09-17 14:56:07, Roman Gushchin wrote: > > > > On Wed, Sep 13, 2017 at 02:29:14PM +0200, Michal Hocko wrote: > > > [...] > > > > > I strongly believe that comparing only leaf memcgs > > > > > is more straightforward and it doesn't lead to unexpected results as > > > > > mentioned before (kill a small memcg which is a part of the larger > > > > > sub-hierarchy). > > > > > > > > One of two main goals of this patchset is to introduce cgroup-level > > > > fairness: bigger cgroups should be affected more than smaller, > > > > despite the size of tasks inside. I believe the same principle > > > > should be used for cgroups. > > > > > > Yes bigger cgroups should be preferred but I fail to see why bigger > > > hierarchies should be considered as well if they are not kill-all. And > > > whether non-leaf memcgs should allow kill-all is not entirely clear to > > > me. What would be the usecase? > > > > We definitely want to support kill-all for non-leaf cgroups. > > A workload can consist of several cgroups and we want to clean up > > the whole thing on OOM. > > Could you be more specific about such a workload? E.g. how can be such a > hierarchy handled consistently when its sub-tree gets killed due to > internal memory pressure? Or just system-wide OOM. > Or do you expect that none of the subtree will > have hard limit configured? And this can also be a case: the whole workload may have hard limit configured, while internal memcgs have only memory.low set for "soft" prioritization. > > But then you just enforce a structural restriction on your configuration > because > root > / \ > A D > /\ > B C > > is a different thing than > root > / | \ > B C D > I actually don't have a strong argument against an approach to select largest leaf or kill-all-set memcg. I think, in practice there will be no much difference. The only real concern I have is that then we have to do the same with oom_priorities (select largest priority tree-wide), and this will limit an ability to enforce the priority by parent cgroup. Thanks!
WARNING: multiple messages have this Message-ID (diff)
From: Roman Gushchin <guro@fb.com> To: Michal Hocko <mhocko@kernel.org> Cc: David Rientjes <rientjes@google.com>, linux-mm@kvack.org, Vladimir Davydov <vdavydov.dev@gmail.com>, Johannes Weiner <hannes@cmpxchg.org>, Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>, Andrew Morton <akpm@linux-foundation.org>, Tejun Heo <tj@kernel.org>, kernel-team@fb.com, cgroups@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [v8 0/4] cgroup-aware OOM killer Date: Fri, 15 Sep 2017 08:23:01 -0700 [thread overview] Message-ID: <20170915152301.GA29379@castle> (raw) In-Reply-To: <20170915105826.hq5afcu2ij7hevb4@dhcp22.suse.cz> On Fri, Sep 15, 2017 at 12:58:26PM +0200, Michal Hocko wrote: > On Thu 14-09-17 09:05:48, Roman Gushchin wrote: > > On Thu, Sep 14, 2017 at 03:40:14PM +0200, Michal Hocko wrote: > > > On Wed 13-09-17 14:56:07, Roman Gushchin wrote: > > > > On Wed, Sep 13, 2017 at 02:29:14PM +0200, Michal Hocko wrote: > > > [...] > > > > > I strongly believe that comparing only leaf memcgs > > > > > is more straightforward and it doesn't lead to unexpected results as > > > > > mentioned before (kill a small memcg which is a part of the larger > > > > > sub-hierarchy). > > > > > > > > One of two main goals of this patchset is to introduce cgroup-level > > > > fairness: bigger cgroups should be affected more than smaller, > > > > despite the size of tasks inside. I believe the same principle > > > > should be used for cgroups. > > > > > > Yes bigger cgroups should be preferred but I fail to see why bigger > > > hierarchies should be considered as well if they are not kill-all. And > > > whether non-leaf memcgs should allow kill-all is not entirely clear to > > > me. What would be the usecase? > > > > We definitely want to support kill-all for non-leaf cgroups. > > A workload can consist of several cgroups and we want to clean up > > the whole thing on OOM. > > Could you be more specific about such a workload? E.g. how can be such a > hierarchy handled consistently when its sub-tree gets killed due to > internal memory pressure? Or just system-wide OOM. > Or do you expect that none of the subtree will > have hard limit configured? And this can also be a case: the whole workload may have hard limit configured, while internal memcgs have only memory.low set for "soft" prioritization. > > But then you just enforce a structural restriction on your configuration > because > root > / \ > A D > /\ > B C > > is a different thing than > root > / | \ > B C D > I actually don't have a strong argument against an approach to select largest leaf or kill-all-set memcg. I think, in practice there will be no much difference. The only real concern I have is that then we have to do the same with oom_priorities (select largest priority tree-wide), and this will limit an ability to enforce the priority by parent cgroup. Thanks! -- 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>
next prev parent reply other threads:[~2017-09-15 15:23 UTC|newest] Thread overview: 168+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-09-11 13:17 [v8 0/4] cgroup-aware OOM killer Roman Gushchin 2017-09-11 13:17 ` Roman Gushchin 2017-09-11 13:17 ` [v8 1/4] mm, oom: refactor the oom_kill_process() function Roman Gushchin 2017-09-11 13:17 ` Roman Gushchin 2017-09-11 20:51 ` David Rientjes 2017-09-11 20:51 ` David Rientjes 2017-09-14 13:42 ` Michal Hocko 2017-09-14 13:42 ` Michal Hocko 2017-09-11 13:17 ` [v8 2/4] mm, oom: cgroup-aware OOM killer Roman Gushchin 2017-09-11 13:17 ` Roman Gushchin 2017-09-13 20:46 ` David Rientjes 2017-09-13 20:46 ` David Rientjes 2017-09-13 21:59 ` Roman Gushchin 2017-09-13 21:59 ` Roman Gushchin 2017-09-13 21:59 ` Roman Gushchin 2017-09-11 13:17 ` [v8 3/4] mm, oom: add cgroup v2 mount option for " Roman Gushchin 2017-09-11 13:17 ` Roman Gushchin 2017-09-11 13:17 ` Roman Gushchin 2017-09-11 20:48 ` David Rientjes 2017-09-11 20:48 ` David Rientjes 2017-09-12 20:01 ` Roman Gushchin 2017-09-12 20:01 ` Roman Gushchin 2017-09-12 20:23 ` David Rientjes 2017-09-12 20:23 ` David Rientjes 2017-09-13 12:23 ` Michal Hocko 2017-09-13 12:23 ` Michal Hocko 2017-09-11 13:17 ` [v8 4/4] mm, oom, docs: describe the " Roman Gushchin 2017-09-11 13:17 ` Roman Gushchin 2017-09-11 20:44 ` [v8 0/4] " David Rientjes 2017-09-11 20:44 ` David Rientjes 2017-09-13 12:29 ` Michal Hocko 2017-09-13 12:29 ` Michal Hocko 2017-09-13 20:46 ` David Rientjes 2017-09-13 20:46 ` David Rientjes 2017-09-14 13:34 ` Michal Hocko 2017-09-14 13:34 ` Michal Hocko 2017-09-14 20:07 ` David Rientjes 2017-09-14 20:07 ` David Rientjes 2017-09-13 21:56 ` Roman Gushchin 2017-09-13 21:56 ` Roman Gushchin 2017-09-14 13:40 ` Michal Hocko 2017-09-14 13:40 ` Michal Hocko 2017-09-14 16:05 ` Roman Gushchin 2017-09-14 16:05 ` Roman Gushchin 2017-09-15 10:58 ` Michal Hocko 2017-09-15 10:58 ` Michal Hocko 2017-09-15 15:23 ` Roman Gushchin [this message] 2017-09-15 15:23 ` Roman Gushchin 2017-09-15 19:55 ` David Rientjes 2017-09-15 19:55 ` David Rientjes 2017-09-15 21:08 ` Roman Gushchin 2017-09-15 21:08 ` Roman Gushchin 2017-09-18 6:20 ` Michal Hocko 2017-09-18 6:20 ` Michal Hocko 2017-09-18 15:02 ` Roman Gushchin 2017-09-18 15:02 ` Roman Gushchin 2017-09-18 15:02 ` Roman Gushchin 2017-09-21 8:30 ` David Rientjes 2017-09-21 8:30 ` David Rientjes 2017-09-19 20:54 ` David Rientjes 2017-09-19 20:54 ` David Rientjes 2017-09-20 22:24 ` Roman Gushchin 2017-09-20 22:24 ` Roman Gushchin 2017-09-21 8:27 ` David Rientjes 2017-09-21 8:27 ` David Rientjes 2017-09-18 6:16 ` Michal Hocko 2017-09-18 6:16 ` Michal Hocko 2017-09-19 20:51 ` David Rientjes 2017-09-19 20:51 ` David Rientjes 2017-09-18 6:14 ` Michal Hocko 2017-09-18 6:14 ` Michal Hocko 2017-09-20 21:53 ` Roman Gushchin 2017-09-20 21:53 ` Roman Gushchin 2017-09-20 21:53 ` Roman Gushchin 2017-09-25 12:24 ` Michal Hocko 2017-09-25 12:24 ` Michal Hocko 2017-09-25 17:00 ` Johannes Weiner 2017-09-25 17:00 ` Johannes Weiner 2017-09-25 18:15 ` Roman Gushchin 2017-09-25 18:15 ` Roman Gushchin 2017-09-25 20:25 ` Michal Hocko 2017-09-25 20:25 ` Michal Hocko 2017-09-25 20:25 ` Michal Hocko 2017-09-26 10:59 ` Roman Gushchin 2017-09-26 10:59 ` Roman Gushchin 2017-09-26 11:21 ` Michal Hocko 2017-09-26 11:21 ` Michal Hocko 2017-09-26 12:13 ` Roman Gushchin 2017-09-26 12:13 ` Roman Gushchin 2017-09-26 12:13 ` Roman Gushchin 2017-09-26 13:30 ` Michal Hocko 2017-09-26 13:30 ` Michal Hocko 2017-09-26 17:26 ` Johannes Weiner 2017-09-26 17:26 ` Johannes Weiner 2017-09-27 3:37 ` Tim Hockin 2017-09-27 3:37 ` Tim Hockin 2017-09-27 7:43 ` Michal Hocko 2017-09-27 7:43 ` Michal Hocko 2017-09-27 10:19 ` Roman Gushchin 2017-09-27 10:19 ` Roman Gushchin 2017-09-27 10:19 ` Roman Gushchin 2017-09-27 15:35 ` Tim Hockin 2017-09-27 15:35 ` Tim Hockin 2017-09-27 16:23 ` Roman Gushchin 2017-09-27 16:23 ` Roman Gushchin 2017-09-27 18:11 ` Tim Hockin 2017-09-27 18:11 ` Tim Hockin 2017-10-01 23:29 ` Shakeel Butt 2017-10-01 23:29 ` Shakeel Butt 2017-10-02 11:56 ` Tetsuo Handa 2017-10-02 11:56 ` Tetsuo Handa 2017-10-02 12:24 ` Michal Hocko 2017-10-02 12:24 ` Michal Hocko 2017-10-02 12:47 ` Roman Gushchin 2017-10-02 12:47 ` Roman Gushchin 2017-10-02 14:29 ` Michal Hocko 2017-10-02 14:29 ` Michal Hocko 2017-10-02 14:29 ` Michal Hocko 2017-10-02 19:00 ` Shakeel Butt 2017-10-02 19:00 ` Shakeel Butt 2017-10-02 19:28 ` Michal Hocko 2017-10-02 19:28 ` Michal Hocko 2017-10-02 19:45 ` Shakeel Butt 2017-10-02 19:45 ` Shakeel Butt 2017-10-02 19:56 ` Michal Hocko 2017-10-02 19:56 ` Michal Hocko 2017-10-02 20:00 ` Tim Hockin 2017-10-02 20:00 ` Tim Hockin 2017-10-02 20:08 ` Michal Hocko 2017-10-02 20:08 ` Michal Hocko 2017-10-02 20:09 ` Shakeel Butt 2017-10-02 20:20 ` Shakeel Butt 2017-10-02 20:20 ` Shakeel Butt 2017-10-02 20:24 ` Shakeel Butt 2017-10-02 20:24 ` Shakeel Butt 2017-10-02 20:34 ` Johannes Weiner 2017-10-02 20:34 ` Johannes Weiner 2017-10-02 20:55 ` Michal Hocko 2017-10-02 20:55 ` Michal Hocko 2017-09-25 22:21 ` David Rientjes 2017-09-25 22:21 ` David Rientjes 2017-09-26 8:46 ` Michal Hocko 2017-09-26 8:46 ` Michal Hocko 2017-09-26 21:04 ` David Rientjes 2017-09-26 21:04 ` David Rientjes 2017-09-27 7:37 ` Michal Hocko 2017-09-27 7:37 ` Michal Hocko 2017-09-27 9:57 ` Roman Gushchin 2017-09-27 9:57 ` Roman Gushchin 2017-09-21 14:21 ` Johannes Weiner 2017-09-21 14:21 ` Johannes Weiner 2017-09-21 21:17 ` David Rientjes 2017-09-21 21:17 ` David Rientjes 2017-09-21 21:17 ` David Rientjes 2017-09-21 21:51 ` Johannes Weiner 2017-09-21 21:51 ` Johannes Weiner 2017-09-22 20:53 ` David Rientjes 2017-09-22 20:53 ` David Rientjes 2017-09-22 15:44 ` Tejun Heo 2017-09-22 15:44 ` Tejun Heo 2017-09-22 15:44 ` Tejun Heo 2017-09-22 20:39 ` David Rientjes 2017-09-22 20:39 ` David Rientjes 2017-09-22 20:39 ` David Rientjes 2017-09-22 21:05 ` Tejun Heo 2017-09-22 21:05 ` Tejun Heo 2017-09-23 8:16 ` David Rientjes 2017-09-23 8:16 ` David Rientjes
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=20170915152301.GA29379@castle \ --to=guro@fb.com \ --cc=akpm@linux-foundation.org \ --cc=cgroups@vger.kernel.org \ --cc=hannes@cmpxchg.org \ --cc=kernel-team@fb.com \ --cc=linux-doc@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mhocko@kernel.org \ --cc=penguin-kernel@i-love.sakura.ne.jp \ --cc=rientjes@google.com \ --cc=tj@kernel.org \ --cc=vdavydov.dev@gmail.com \ /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.