From: "Doug Smythies" <dsmythies@telus.net>
To: js1304@gmail.com, 'Andrew Morton' <akpm@linux-foundation.org>
Cc: 'Christoph Lameter' <cl@linux.com>,
'Pekka Enberg' <penberg@kernel.org>,
'David Rientjes' <rientjes@google.com>,
'Johannes Weiner' <hannes@cmpxchg.org>,
'Vladimir Davydov' <vdavydov.dev@gmail.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
'Joonsoo Kim' <iamjoonsoo.kim@lge.com>,
stable@vger.kernel.org
Subject: RE: [PATCH] mm/slab: fix kmemcg cache creation delayed issue
Date: Thu, 6 Oct 2016 09:02:00 -0700 [thread overview]
Message-ID: <002b01d21fea$fb0bab60$f1230220$@net> (raw)
In-Reply-To: s238betearAHps239b0z1X
It was my (limited) understanding that the subsequent 2 patch set
superseded this patch. Indeed, the 2 patch set seems to solve
both the SLAB and SLUB bug reports.
References:
https://bugzilla.kernel.org/show_bug.cgi?id=172981
https://bugzilla.kernel.org/show_bug.cgi?id=172991
https://patchwork.kernel.org/patch/9361853
https://patchwork.kernel.org/patch/9359271
On 2016.10.05 23:21 Joonsoo Kim wrote:
> From: Joonsoo Kim <iamjoonsoo.kim@lge.com>
>
> There is a bug report that SLAB makes extreme load average due to
> over 2000 kworker thread.
>
> https://bugzilla.kernel.org/show_bug.cgi?id=172981
>
> This issue is caused by kmemcg feature that try to create new set of
> kmem_caches for each memcg. Recently, kmem_cache creation is slowed by
> synchronize_sched() and futher kmem_cache creation is also delayed
> since kmem_cache creation is synchronized by a global slab_mutex lock.
> So, the number of kworker that try to create kmem_cache increases quitely.
> synchronize_sched() is for lockless access to node's shared array but
> it's not needed when a new kmem_cache is created. So, this patch
> rules out that case.
>
> Fixes: 801faf0db894 ("mm/slab: lockless decision to grow cache")
> Cc: stable@vger.kernel.org
> Reported-by: Doug Smythies <dsmythies@telus.net>
> Tested-by: Doug Smythies <dsmythies@telus.net>
> Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
> ---
> mm/slab.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/slab.c b/mm/slab.c
> index 6508b4d..3c83c29 100644
> --- a/mm/slab.c
> +++ b/mm/slab.c
> @@ -961,7 +961,7 @@ static int setup_kmem_cache_node(struct kmem_cache *cachep,
> * guaranteed to be valid until irq is re-enabled, because it will be
> * freed after synchronize_sched().
> */
> - if (force_change)
> + if (old_shared && force_change)
> synchronize_sched();
>
> fail:
> --
> 1.9.1
--
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: "Doug Smythies" <dsmythies@telus.net>
To: <js1304@gmail.com>, "'Andrew Morton'" <akpm@linux-foundation.org>
Cc: "'Christoph Lameter'" <cl@linux.com>,
"'Pekka Enberg'" <penberg@kernel.org>,
"'David Rientjes'" <rientjes@google.com>,
"'Johannes Weiner'" <hannes@cmpxchg.org>,
"'Vladimir Davydov'" <vdavydov.dev@gmail.com>,
<linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>,
"'Joonsoo Kim'" <iamjoonsoo.kim@lge.com>,
<stable@vger.kernel.org>
Subject: RE: [PATCH] mm/slab: fix kmemcg cache creation delayed issue
Date: Thu, 6 Oct 2016 09:02:00 -0700 [thread overview]
Message-ID: <002b01d21fea$fb0bab60$f1230220$@net> (raw)
In-Reply-To: s238betearAHps239b0z1X
It was my (limited) understanding that the subsequent 2 patch set
superseded this patch. Indeed, the 2 patch set seems to solve
both the SLAB and SLUB bug reports.
References:
https://bugzilla.kernel.org/show_bug.cgi?id=172981
https://bugzilla.kernel.org/show_bug.cgi?id=172991
https://patchwork.kernel.org/patch/9361853
https://patchwork.kernel.org/patch/9359271
On 2016.10.05 23:21 Joonsoo Kim wrote:
> From: Joonsoo Kim <iamjoonsoo.kim@lge.com>
>
> There is a bug report that SLAB makes extreme load average due to
> over 2000 kworker thread.
>
> https://bugzilla.kernel.org/show_bug.cgi?id=172981
>
> This issue is caused by kmemcg feature that try to create new set of
> kmem_caches for each memcg. Recently, kmem_cache creation is slowed by
> synchronize_sched() and futher kmem_cache creation is also delayed
> since kmem_cache creation is synchronized by a global slab_mutex lock.
> So, the number of kworker that try to create kmem_cache increases quitely.
> synchronize_sched() is for lockless access to node's shared array but
> it's not needed when a new kmem_cache is created. So, this patch
> rules out that case.
>
> Fixes: 801faf0db894 ("mm/slab: lockless decision to grow cache")
> Cc: stable@vger.kernel.org
> Reported-by: Doug Smythies <dsmythies@telus.net>
> Tested-by: Doug Smythies <dsmythies@telus.net>
> Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
> ---
> mm/slab.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/slab.c b/mm/slab.c
> index 6508b4d..3c83c29 100644
> --- a/mm/slab.c
> +++ b/mm/slab.c
> @@ -961,7 +961,7 @@ static int setup_kmem_cache_node(struct kmem_cache *cachep,
> * guaranteed to be valid until irq is re-enabled, because it will be
> * freed after synchronize_sched().
> */
> - if (force_change)
> + if (old_shared && force_change)
> synchronize_sched();
>
> fail:
> --
> 1.9.1
WARNING: multiple messages have this Message-ID (diff)
From: "Doug Smythies" <dsmythies@telus.net>
To: <js1304@gmail.com>, "'Andrew Morton'" <akpm@linux-foundation.org>
Cc: "'Christoph Lameter'" <cl@linux.com>,
"'Pekka Enberg'" <penberg@kernel.org>,
"'David Rientjes'" <rientjes@google.com>,
"'Johannes Weiner'" <hannes@cmpxchg.org>,
"'Vladimir Davydov'" <vdavydov.dev@gmail.com>,
<linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>,
"'Joonsoo Kim'" <iamjoonsoo.kim@lge.com>,
<stable@vger.kernel.org>
Subject: RE: [PATCH] mm/slab: fix kmemcg cache creation delayed issue
Date: Thu, 6 Oct 2016 09:02:00 -0700 [thread overview]
Message-ID: <002b01d21fea$fb0bab60$f1230220$@net> (raw)
In-Reply-To: s238betearAHps239b0z1X
It was my (limited) understanding that the subsequent 2 patch set
superseded this patch. Indeed, the 2 patch set seems to solve
both the SLAB and SLUB bug reports.
References:
https://bugzilla.kernel.org/show_bug.cgi?id=172981
https://bugzilla.kernel.org/show_bug.cgi?id=172991
https://patchwork.kernel.org/patch/9361853
https://patchwork.kernel.org/patch/9359271
On 2016.10.05 23:21 Joonsoo Kim wrote:
> From: Joonsoo Kim <iamjoonsoo.kim@lge.com>
>
> There is a bug report that SLAB makes extreme load average due to
> over 2000 kworker thread.
>
> https://bugzilla.kernel.org/show_bug.cgi?id=172981
>
> This issue is caused by kmemcg feature that try to create new set of
> kmem_caches for each memcg. Recently, kmem_cache creation is slowed by
> synchronize_sched() and futher kmem_cache creation is also delayed
> since kmem_cache creation is synchronized by a global slab_mutex lock.
> So, the number of kworker that try to create kmem_cache increases quitely.
> synchronize_sched() is for lockless access to node's shared array but
> it's not needed when a new kmem_cache is created. So, this patch
> rules out that case.
>
> Fixes: 801faf0db894 ("mm/slab: lockless decision to grow cache")
> Cc: stable@vger.kernel.org
> Reported-by: Doug Smythies <dsmythies@telus.net>
> Tested-by: Doug Smythies <dsmythies@telus.net>
> Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
> ---
> mm/slab.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/slab.c b/mm/slab.c
> index 6508b4d..3c83c29 100644
> --- a/mm/slab.c
> +++ b/mm/slab.c
> @@ -961,7 +961,7 @@ static int setup_kmem_cache_node(struct kmem_cache *cachep,
> * guaranteed to be valid until irq is re-enabled, because it will be
> * freed after synchronize_sched().
> */
> - if (force_change)
> + if (old_shared && force_change)
> synchronize_sched();
>
> fail:
> --
> 1.9.1
--
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 reply other threads:[~2016-10-06 16:02 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-06 16:02 Doug Smythies [this message]
2016-10-06 16:02 ` [PATCH] mm/slab: fix kmemcg cache creation delayed issue Doug Smythies
2016-10-06 16:02 ` Doug Smythies
2016-10-07 5:14 ` Joonsoo Kim
2016-10-07 5:14 ` Joonsoo Kim
2016-10-07 8:20 ` Michal Hocko
2016-10-07 8:20 ` Michal Hocko
2016-10-13 7:42 ` Joonsoo Kim
2016-10-13 7:42 ` Joonsoo Kim
-- strict thread matches above, loose matches on Subject: below --
2016-10-06 6:20 js1304
2016-10-06 6:20 ` js1304
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='002b01d21fea$fb0bab60$f1230220$@net' \
--to=dsmythies@telus.net \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=hannes@cmpxchg.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=js1304@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=stable@vger.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: 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.