From: Johannes Weiner <hannes@cmpxchg.org>
To: Vladimir Davydov <vdavydov@virtuozzo.com>
Cc: Tejun Heo <tj@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Michal Hocko <mhocko@suse.cz>, Li Zefan <lizefan@huawei.com>,
linux-mm@kvack.org, cgroups@vger.kernel.org,
linux-kernel@vger.kernel.org, kernel-team@fb.com
Subject: Re: [PATCH 3/3] mm: memcontrol: fix cgroup creation failure after many small jobs
Date: Tue, 21 Jun 2016 11:46:01 -0400 [thread overview]
Message-ID: <20160621154601.GA22431@cmpxchg.org> (raw)
In-Reply-To: <20160621101650.GD15970@esperanza>
On Tue, Jun 21, 2016 at 01:16:51PM +0300, Vladimir Davydov wrote:
> On Fri, Jun 17, 2016 at 12:25:16PM -0400, Johannes Weiner wrote:
> > After this patch, the IDs get released upon cgroup destruction and the
> > cache and css objects get released once memory reclaim kicks in.
>
> With 65K cgroups it will take the reclaimer a substantial amount of time
> to iterate over all of them, which might result in latency spikes.
> Probably, to avoid that, we could move pages from a dead cgroup's lru to
> its parent's one on offline while still leaving dead cgroups pinned,
> like we do in case of list_lru entries.
Yep, that is true. list_lru is a bit easier because the walker stays
in the context of the original LRU list, whereas the cache/anon LRUs
are not. We'd have to have mem_cgroup_page_lruvec() etc. do a parent
walk to find the closest live ancestor. Maybe you have a better idea?
But it's definitely worth considering. I'll think more about it.
> > Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
>
> Reviewed-by: Vladimir Davydov <vdavydov@virtuozzo.com>
Thanks!
> > +static struct idr mem_cgroup_idr;
>
> static DEFINE_IDR(mem_cgroup_idr);
Oops, good catch. Andrew, could you kindly fold this?
From d1261ede8f975a5fccb2e9125562260e4b4b4f3d Mon Sep 17 00:00:00 2001
From: Johannes Weiner <hannes@cmpxchg.org>
Date: Tue, 21 Jun 2016 11:36:13 -0400
Subject: [PATCH] mm: memcontrol: fix cgroup creation failure after many small
jobs fix
init the IDR
Reported-by: Vladimir Davydov <vdavydov@virtuozzo.com>
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
---
mm/memcontrol.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index dc92b2df2585..b0de1342eab2 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -4081,7 +4081,7 @@ static struct cftype mem_cgroup_legacy_files[] = {
* those references are manageable from userspace.
*/
-static struct idr mem_cgroup_idr;
+static DEFINE_IDR(mem_cgroup_idr);
static void mem_cgroup_id_get(struct mem_cgroup *memcg)
{
--
2.8.3
--
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: Johannes Weiner <hannes@cmpxchg.org>
To: Vladimir Davydov <vdavydov@virtuozzo.com>
Cc: Tejun Heo <tj@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Michal Hocko <mhocko@suse.cz>, Li Zefan <lizefan@huawei.com>,
linux-mm@kvack.org, cgroups@vger.kernel.org,
linux-kernel@vger.kernel.org, kernel-team@fb.com
Subject: Re: [PATCH 3/3] mm: memcontrol: fix cgroup creation failure after many small jobs
Date: Tue, 21 Jun 2016 11:46:01 -0400 [thread overview]
Message-ID: <20160621154601.GA22431@cmpxchg.org> (raw)
In-Reply-To: <20160621101650.GD15970@esperanza>
On Tue, Jun 21, 2016 at 01:16:51PM +0300, Vladimir Davydov wrote:
> On Fri, Jun 17, 2016 at 12:25:16PM -0400, Johannes Weiner wrote:
> > After this patch, the IDs get released upon cgroup destruction and the
> > cache and css objects get released once memory reclaim kicks in.
>
> With 65K cgroups it will take the reclaimer a substantial amount of time
> to iterate over all of them, which might result in latency spikes.
> Probably, to avoid that, we could move pages from a dead cgroup's lru to
> its parent's one on offline while still leaving dead cgroups pinned,
> like we do in case of list_lru entries.
Yep, that is true. list_lru is a bit easier because the walker stays
in the context of the original LRU list, whereas the cache/anon LRUs
are not. We'd have to have mem_cgroup_page_lruvec() etc. do a parent
walk to find the closest live ancestor. Maybe you have a better idea?
But it's definitely worth considering. I'll think more about it.
> > Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
>
> Reviewed-by: Vladimir Davydov <vdavydov@virtuozzo.com>
Thanks!
> > +static struct idr mem_cgroup_idr;
>
> static DEFINE_IDR(mem_cgroup_idr);
Oops, good catch. Andrew, could you kindly fold this?
WARNING: multiple messages have this Message-ID (diff)
From: Johannes Weiner <hannes@cmpxchg.org>
To: Vladimir Davydov <vdavydov@virtuozzo.com>
Cc: Tejun Heo <tj@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Michal Hocko <mhocko@suse.cz>, Li Zefan <lizefan@huawei.com>,
linux-mm@kvack.org, cgroups@vger.kernel.org,
linux-kernel@vger.kernel.org, kernel-team@fb.com
Subject: Re: [PATCH 3/3] mm: memcontrol: fix cgroup creation failure after many small jobs
Date: Tue, 21 Jun 2016 11:46:01 -0400 [thread overview]
Message-ID: <20160621154601.GA22431@cmpxchg.org> (raw)
In-Reply-To: <20160621101650.GD15970@esperanza>
On Tue, Jun 21, 2016 at 01:16:51PM +0300, Vladimir Davydov wrote:
> On Fri, Jun 17, 2016 at 12:25:16PM -0400, Johannes Weiner wrote:
> > After this patch, the IDs get released upon cgroup destruction and the
> > cache and css objects get released once memory reclaim kicks in.
>
> With 65K cgroups it will take the reclaimer a substantial amount of time
> to iterate over all of them, which might result in latency spikes.
> Probably, to avoid that, we could move pages from a dead cgroup's lru to
> its parent's one on offline while still leaving dead cgroups pinned,
> like we do in case of list_lru entries.
Yep, that is true. list_lru is a bit easier because the walker stays
in the context of the original LRU list, whereas the cache/anon LRUs
are not. We'd have to have mem_cgroup_page_lruvec() etc. do a parent
walk to find the closest live ancestor. Maybe you have a better idea?
But it's definitely worth considering. I'll think more about it.
> > Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
>
> Reviewed-by: Vladimir Davydov <vdavydov@virtuozzo.com>
Thanks!
> > +static struct idr mem_cgroup_idr;
>
> static DEFINE_IDR(mem_cgroup_idr);
Oops, good catch. Andrew, could you kindly fold this?
>From d1261ede8f975a5fccb2e9125562260e4b4b4f3d Mon Sep 17 00:00:00 2001
From: Johannes Weiner <hannes@cmpxchg.org>
Date: Tue, 21 Jun 2016 11:36:13 -0400
Subject: [PATCH] mm: memcontrol: fix cgroup creation failure after many small
jobs fix
init the IDR
Reported-by: Vladimir Davydov <vdavydov@virtuozzo.com>
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
---
mm/memcontrol.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index dc92b2df2585..b0de1342eab2 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -4081,7 +4081,7 @@ static struct cftype mem_cgroup_legacy_files[] = {
* those references are manageable from userspace.
*/
-static struct idr mem_cgroup_idr;
+static DEFINE_IDR(mem_cgroup_idr);
static void mem_cgroup_id_get(struct mem_cgroup *memcg)
{
--
2.8.3
next prev parent reply other threads:[~2016-06-21 15:46 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-16 3:42 [PATCH] mm: memcontrol: fix cgroup creation failure after many small jobs Johannes Weiner
2016-06-16 3:42 ` Johannes Weiner
2016-06-16 20:06 ` Tejun Heo
2016-06-16 20:06 ` Tejun Heo
2016-06-17 16:23 ` Johannes Weiner
2016-06-17 16:23 ` Johannes Weiner
[not found] ` <20160617162310.GA19084-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2016-06-17 16:23 ` [PATCH 1/3] cgroup: fix idr leak for the first cgroup root Johannes Weiner
2016-06-17 16:23 ` Johannes Weiner
2016-06-17 16:23 ` Johannes Weiner
2016-06-17 16:24 ` [PATCH 2/3] cgroup: remove unnecessary 0 check from css_from_id() Johannes Weiner
2016-06-17 16:24 ` Johannes Weiner
2016-06-17 16:24 ` Johannes Weiner
[not found] ` <20160617162427.GC19084-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2016-06-17 18:17 ` Tejun Heo
2016-06-17 18:17 ` Tejun Heo
2016-06-17 18:17 ` Tejun Heo
2016-06-17 16:25 ` [PATCH 3/3] mm: memcontrol: fix cgroup creation failure after many small jobs Johannes Weiner
2016-06-17 16:25 ` Johannes Weiner
2016-06-17 18:18 ` Tejun Heo
2016-06-17 18:18 ` Tejun Heo
2016-06-20 6:14 ` Nikolay Borisov
2016-06-20 6:14 ` Nikolay Borisov
2016-06-21 10:16 ` Vladimir Davydov
2016-06-21 10:16 ` Vladimir Davydov
2016-06-21 15:46 ` Johannes Weiner [this message]
2016-06-21 15:46 ` Johannes Weiner
2016-06-21 15:46 ` Johannes Weiner
2016-06-17 9:06 ` [PATCH] " Vladimir Davydov
2016-06-17 9:06 ` Vladimir Davydov
2016-06-17 16:40 ` Johannes Weiner
2016-06-17 16:40 ` Johannes Weiner
2016-06-17 16:40 ` Johannes Weiner
2016-07-14 15:37 ` Johannes Weiner
2016-07-14 15:37 ` Johannes Weiner
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=20160621154601.GA22431@cmpxchg.org \
--to=hannes@cmpxchg.org \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=kernel-team@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lizefan@huawei.com \
--cc=mhocko@suse.cz \
--cc=tj@kernel.org \
--cc=vdavydov@virtuozzo.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: 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.