From: Roman Gushchin <guro-b10kYP2dOMg@public.gmane.org>
To: Michal Hocko <mhocko-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
Vladimir Davydov
<vdavydov.dev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>,
Tetsuo Handa
<penguin-kernel-JPay3/Yim36HaxMnTkn67Xf5DAMn2ifp@public.gmane.org>,
David Rientjes <rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
Andrew Morton
<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
kernel-team-b10kYP2dOMg@public.gmane.org,
cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [v11 4/6] mm, oom: introduce memory.oom_group
Date: Fri, 6 Oct 2017 13:04:35 +0100 [thread overview]
Message-ID: <20171006120435.GA22702@castle.dhcp.TheFacebook.com> (raw)
In-Reply-To: <20171005143104.wo5xstpe7mhkdlbr-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
On Thu, Oct 05, 2017 at 04:31:04PM +0200, Michal Hocko wrote:
> Btw. here is how I would do the recursive oom badness. The diff is not
> the nicest one because there is some code moving but the resulting code
> is smaller and imho easier to grasp. Only compile tested though
Thanks!
I'm not against this approach, and maybe it can lead to a better code,
but the version you sent is just not there yet.
There are some problems with it:
1) If there are nested cgroups with oom_group set, you will calculate
a badness multiple times, and rely on the fact, that top memcg will
become the largest score. It can be optimized, of course, but it's
additional code.
2) cgroup_has_tasks() probably requires additional locking.
Maybe it's ok to read nr_populated_csets without explicit locking,
but it's not obvious for me.
3) Returning -1 from memcg_oom_badness() if eligible is equal to 0
is suspicious.
Right now your version has exactly the same amount of code
(skipping comments). I assume, this approach just requires some additional
thinking/rework.
Anyway, thank you for sharing this!
> ---
> diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
> index 085056e562b1..9cdba4682198 100644
> --- a/include/linux/cgroup.h
> +++ b/include/linux/cgroup.h
> @@ -122,6 +122,11 @@ void cgroup_free(struct task_struct *p);
> int cgroup_init_early(void);
> int cgroup_init(void);
>
> +static bool cgroup_has_tasks(struct cgroup *cgrp)
> +{
> + return cgrp->nr_populated_csets;
> +}
> +
> /*
> * Iteration helpers and macros.
> */
> diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
> index 8dacf73ad57e..a2dd7e3ffe23 100644
> --- a/kernel/cgroup/cgroup.c
> +++ b/kernel/cgroup/cgroup.c
> @@ -319,11 +319,6 @@ static void cgroup_idr_remove(struct idr *idr, int id)
> spin_unlock_bh(&cgroup_idr_lock);
> }
>
> -static bool cgroup_has_tasks(struct cgroup *cgrp)
> -{
> - return cgrp->nr_populated_csets;
> -}
> -
> bool cgroup_is_threaded(struct cgroup *cgrp)
> {
> return cgrp->dom_cgrp != cgrp;
WARNING: multiple messages have this Message-ID (diff)
From: Roman Gushchin <guro@fb.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: linux-mm@kvack.org, Vladimir Davydov <vdavydov.dev@gmail.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
David Rientjes <rientjes@google.com>,
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: [v11 4/6] mm, oom: introduce memory.oom_group
Date: Fri, 6 Oct 2017 13:04:35 +0100 [thread overview]
Message-ID: <20171006120435.GA22702@castle.dhcp.TheFacebook.com> (raw)
In-Reply-To: <20171005143104.wo5xstpe7mhkdlbr@dhcp22.suse.cz>
On Thu, Oct 05, 2017 at 04:31:04PM +0200, Michal Hocko wrote:
> Btw. here is how I would do the recursive oom badness. The diff is not
> the nicest one because there is some code moving but the resulting code
> is smaller and imho easier to grasp. Only compile tested though
Thanks!
I'm not against this approach, and maybe it can lead to a better code,
but the version you sent is just not there yet.
There are some problems with it:
1) If there are nested cgroups with oom_group set, you will calculate
a badness multiple times, and rely on the fact, that top memcg will
become the largest score. It can be optimized, of course, but it's
additional code.
2) cgroup_has_tasks() probably requires additional locking.
Maybe it's ok to read nr_populated_csets without explicit locking,
but it's not obvious for me.
3) Returning -1 from memcg_oom_badness() if eligible is equal to 0
is suspicious.
Right now your version has exactly the same amount of code
(skipping comments). I assume, this approach just requires some additional
thinking/rework.
Anyway, thank you for sharing this!
> ---
> diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
> index 085056e562b1..9cdba4682198 100644
> --- a/include/linux/cgroup.h
> +++ b/include/linux/cgroup.h
> @@ -122,6 +122,11 @@ void cgroup_free(struct task_struct *p);
> int cgroup_init_early(void);
> int cgroup_init(void);
>
> +static bool cgroup_has_tasks(struct cgroup *cgrp)
> +{
> + return cgrp->nr_populated_csets;
> +}
> +
> /*
> * Iteration helpers and macros.
> */
> diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
> index 8dacf73ad57e..a2dd7e3ffe23 100644
> --- a/kernel/cgroup/cgroup.c
> +++ b/kernel/cgroup/cgroup.c
> @@ -319,11 +319,6 @@ static void cgroup_idr_remove(struct idr *idr, int id)
> spin_unlock_bh(&cgroup_idr_lock);
> }
>
> -static bool cgroup_has_tasks(struct cgroup *cgrp)
> -{
> - return cgrp->nr_populated_csets;
> -}
> -
> bool cgroup_is_threaded(struct cgroup *cgrp)
> {
> return cgrp->dom_cgrp != cgrp;
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Roman Gushchin <guro@fb.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: <linux-mm@kvack.org>, Vladimir Davydov <vdavydov.dev@gmail.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
David Rientjes <rientjes@google.com>,
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: [v11 4/6] mm, oom: introduce memory.oom_group
Date: Fri, 6 Oct 2017 13:04:35 +0100 [thread overview]
Message-ID: <20171006120435.GA22702@castle.dhcp.TheFacebook.com> (raw)
In-Reply-To: <20171005143104.wo5xstpe7mhkdlbr@dhcp22.suse.cz>
On Thu, Oct 05, 2017 at 04:31:04PM +0200, Michal Hocko wrote:
> Btw. here is how I would do the recursive oom badness. The diff is not
> the nicest one because there is some code moving but the resulting code
> is smaller and imho easier to grasp. Only compile tested though
Thanks!
I'm not against this approach, and maybe it can lead to a better code,
but the version you sent is just not there yet.
There are some problems with it:
1) If there are nested cgroups with oom_group set, you will calculate
a badness multiple times, and rely on the fact, that top memcg will
become the largest score. It can be optimized, of course, but it's
additional code.
2) cgroup_has_tasks() probably requires additional locking.
Maybe it's ok to read nr_populated_csets without explicit locking,
but it's not obvious for me.
3) Returning -1 from memcg_oom_badness() if eligible is equal to 0
is suspicious.
Right now your version has exactly the same amount of code
(skipping comments). I assume, this approach just requires some additional
thinking/rework.
Anyway, thank you for sharing this!
> ---
> diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
> index 085056e562b1..9cdba4682198 100644
> --- a/include/linux/cgroup.h
> +++ b/include/linux/cgroup.h
> @@ -122,6 +122,11 @@ void cgroup_free(struct task_struct *p);
> int cgroup_init_early(void);
> int cgroup_init(void);
>
> +static bool cgroup_has_tasks(struct cgroup *cgrp)
> +{
> + return cgrp->nr_populated_csets;
> +}
> +
> /*
> * Iteration helpers and macros.
> */
> diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
> index 8dacf73ad57e..a2dd7e3ffe23 100644
> --- a/kernel/cgroup/cgroup.c
> +++ b/kernel/cgroup/cgroup.c
> @@ -319,11 +319,6 @@ static void cgroup_idr_remove(struct idr *idr, int id)
> spin_unlock_bh(&cgroup_idr_lock);
> }
>
> -static bool cgroup_has_tasks(struct cgroup *cgrp)
> -{
> - return cgrp->nr_populated_csets;
> -}
> -
> bool cgroup_is_threaded(struct cgroup *cgrp)
> {
> return cgrp->dom_cgrp != cgrp;
next prev parent reply other threads:[~2017-10-06 12:04 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-05 13:04 [v11 0/6] cgroup-aware OOM killer Roman Gushchin
2017-10-05 13:04 ` Roman Gushchin
2017-10-05 13:04 ` Roman Gushchin
2017-10-05 13:04 ` [v11 1/6] mm, oom: refactor the oom_kill_process() function Roman Gushchin
2017-10-05 13:04 ` Roman Gushchin
2017-10-05 13:04 ` Roman Gushchin
2017-10-05 13:04 ` [v11 2/6] mm: implement mem_cgroup_scan_tasks() for the root memory cgroup Roman Gushchin
2017-10-05 13:04 ` Roman Gushchin
[not found] ` <20171005130454.5590-3-guro-b10kYP2dOMg@public.gmane.org>
2017-10-09 21:11 ` David Rientjes
2017-10-09 21:11 ` David Rientjes
2017-10-09 21:11 ` David Rientjes
2017-10-05 13:04 ` [v11 3/6] mm, oom: cgroup-aware OOM killer Roman Gushchin
2017-10-05 13:04 ` Roman Gushchin
[not found] ` <20171005130454.5590-4-guro-b10kYP2dOMg@public.gmane.org>
2017-10-05 14:27 ` Michal Hocko
2017-10-05 14:27 ` Michal Hocko
2017-10-05 14:27 ` Michal Hocko
2017-10-09 21:52 ` David Rientjes
2017-10-09 21:52 ` David Rientjes
[not found] ` <alpine.DEB.2.10.1710091414260.59643-X6Q0R45D7oAcqpCFd4KODRPsWskHk0ljAL8bYrjMMd8@public.gmane.org>
2017-10-10 8:18 ` Michal Hocko
2017-10-10 8:18 ` Michal Hocko
2017-10-10 8:18 ` Michal Hocko
2017-10-10 12:23 ` Roman Gushchin
2017-10-10 12:23 ` Roman Gushchin
2017-10-10 21:13 ` David Rientjes
2017-10-10 21:13 ` David Rientjes
[not found] ` <alpine.DEB.2.10.1710101345370.28262-X6Q0R45D7oAcqpCFd4KODRPsWskHk0ljAL8bYrjMMd8@public.gmane.org>
2017-10-10 22:04 ` Roman Gushchin
2017-10-10 22:04 ` Roman Gushchin
2017-10-10 22:04 ` Roman Gushchin
2017-10-11 20:21 ` David Rientjes
2017-10-11 20:21 ` David Rientjes
[not found] ` <alpine.DEB.2.10.1710111247390.98307-X6Q0R45D7oAcqpCFd4KODRPsWskHk0ljAL8bYrjMMd8@public.gmane.org>
2017-10-11 21:49 ` Roman Gushchin
2017-10-11 21:49 ` Roman Gushchin
2017-10-11 21:49 ` Roman Gushchin
2017-10-12 21:50 ` David Rientjes
2017-10-12 21:50 ` David Rientjes
2017-10-13 13:32 ` Roman Gushchin
2017-10-13 13:32 ` Roman Gushchin
2017-10-13 13:32 ` Roman Gushchin
[not found] ` <20171013133219.GA5363-B3w7+ongkCiLfgCeKHXN1g2O0Ztt9esIQQ4Iyu8u01E@public.gmane.org>
2017-10-13 21:31 ` David Rientjes
2017-10-13 21:31 ` David Rientjes
2017-10-13 21:31 ` David Rientjes
2017-10-11 13:08 ` Michal Hocko
2017-10-11 13:08 ` Michal Hocko
2017-10-11 20:27 ` David Rientjes
2017-10-11 20:27 ` David Rientjes
2017-10-12 6:33 ` Michal Hocko
2017-10-12 6:33 ` Michal Hocko
2017-10-11 16:10 ` Roman Gushchin
2017-10-11 16:10 ` Roman Gushchin
2017-10-11 16:10 ` Roman Gushchin
[not found] ` <20171005130454.5590-1-guro-b10kYP2dOMg@public.gmane.org>
2017-10-05 13:04 ` [v11 4/6] mm, oom: introduce memory.oom_group Roman Gushchin
2017-10-05 13:04 ` Roman Gushchin
2017-10-05 13:04 ` Roman Gushchin
2017-10-05 14:29 ` Michal Hocko
2017-10-05 14:29 ` Michal Hocko
2017-10-05 14:31 ` Michal Hocko
2017-10-05 14:31 ` Michal Hocko
[not found] ` <20171005143104.wo5xstpe7mhkdlbr-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2017-10-06 12:04 ` Roman Gushchin [this message]
2017-10-06 12:04 ` Roman Gushchin
2017-10-06 12:04 ` Roman Gushchin
2017-10-06 12:17 ` Michal Hocko
2017-10-06 12:17 ` Michal Hocko
2017-10-05 13:04 ` [v11 5/6] mm, oom: add cgroup v2 mount option for cgroup-aware OOM killer Roman Gushchin
2017-10-05 13:04 ` Roman Gushchin
2017-10-05 13:04 ` [v11 6/6] mm, oom, docs: describe the " Roman Gushchin
2017-10-05 13:04 ` Roman Gushchin
2017-10-05 13:04 ` Roman Gushchin
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=20171006120435.GA22702@castle.dhcp.TheFacebook.com \
--to=guro-b10kyp2domg@public.gmane.org \
--cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org \
--cc=kernel-team-b10kYP2dOMg@public.gmane.org \
--cc=linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
--cc=mhocko-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=penguin-kernel-JPay3/Yim36HaxMnTkn67Xf5DAMn2ifp@public.gmane.org \
--cc=rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
--cc=tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=vdavydov.dev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.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: link
Be 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.