All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Tejun Heo <tj@kernel.org>
Cc: Christoph Lameter <cl@linux.com>,
	Pekka Enberg <penberg@kernel.org>,
	David Rientjes <rientjes@google.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Vladimir Davydov <vdavydov.dev@gmail.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	cgroups@vger.kernel.org, Michal Hocko <mhocko@kernel.org>,
	kernel-team@fb.com
Subject: Re: [PATCH] slub: make sysfs directories for memcg sub-caches optional
Date: Mon, 6 Feb 2017 16:22:13 -0800	[thread overview]
Message-ID: <20170206162213.30f909b5ce4c681e2217fb4f@linux-foundation.org> (raw)
In-Reply-To: <20170204145203.GB26958@mtj.duckdns.org>

On Sat, 4 Feb 2017 09:52:03 -0500 Tejun Heo <tj@kernel.org> wrote:

> SLUB creates a per-cache directory under /sys/kernel/slab which hosts
> a bunch of debug files.  Usually, there aren't that many caches on a
> system and this doesn't really matter; however, if memcg is in use,
> each cache can have per-cgroup sub-caches.  SLUB creates the same
> directories for these sub-caches under /sys/kernel/slab/$CACHE/cgroup.
> 
> Unfortunately, because there can be a lot of cgroups, active or
> draining, the product of the numbers of caches, cgroups and files in
> each directory can reach a very high number - hundreds of thousands is
> commonplace.  Millions and beyond aren't difficult to reach either.
> 
> What's under /sys/kernel/slab is primarily for debugging and the
> information and control on the a root cache already cover its
> sub-caches.  While having a separate directory for each sub-cache can
> be helpful for development, it doesn't make much sense to pay this
> amount of overhead by default.
> 
> This patch introduces a boot parameter slub_memcg_sysfs which
> determines whether to create sysfs directories for per-memcg
> sub-caches.  It also adds CONFIG_SLUB_MEMCG_SYSFS_ON which determines
> the boot parameter's default value and defaults to 0.
> 
> ...
>
>  #ifdef CONFIG_MEMCG
> -	if (is_root_cache(s)) {
> +	if (is_root_cache(s) && memcg_sysfs_enabled) {

This could be turned on and off after bootup but I guess the result
could be pretty confusing.

However there would be useful use cases?  The user would normally have
this disabled but if he wants to do a bit of debugging then turn this
on, create a memcg, have a poke around then turn the feature off again.

>  		s->memcg_kset = kset_create_and_add("cgroup", NULL, &s->kobj);
>  		if (!s->memcg_kset) {
>  			err = -ENOMEM;
> @@ -5673,7 +5695,8 @@ static void sysfs_slab_remove(struct kme
>  		return;
>  
>  #ifdef CONFIG_MEMCG
> -	kset_unregister(s->memcg_kset);
> +	if (s->memcg_kset)
> +		kset_unregister(s->memcg_kset);

kset_unregister(NULL) is legal

--- a/mm/slub.c~slub-make-sysfs-directories-for-memcg-sub-caches-optional-fix
+++ a/mm/slub.c
@@ -5699,8 +5699,7 @@ static void sysfs_slab_remove(struct kme
 		return;
 
 #ifdef CONFIG_MEMCG
-	if (s->memcg_kset)
-		kset_unregister(s->memcg_kset);
+	kset_unregister(s->memcg_kset);
 #endif
 	kobject_uevent(&s->kobj, KOBJ_REMOVE);
 	kobject_del(&s->kobj);
_

WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: Tejun Heo <tj@kernel.org>
Cc: Christoph Lameter <cl@linux.com>,
	Pekka Enberg <penberg@kernel.org>,
	David Rientjes <rientjes@google.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Vladimir Davydov <vdavydov.dev@gmail.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	cgroups@vger.kernel.org, Michal Hocko <mhocko@kernel.org>,
	kernel-team@fb.com
Subject: Re: [PATCH] slub: make sysfs directories for memcg sub-caches optional
Date: Mon, 6 Feb 2017 16:22:13 -0800	[thread overview]
Message-ID: <20170206162213.30f909b5ce4c681e2217fb4f@linux-foundation.org> (raw)
In-Reply-To: <20170204145203.GB26958@mtj.duckdns.org>

On Sat, 4 Feb 2017 09:52:03 -0500 Tejun Heo <tj@kernel.org> wrote:

> SLUB creates a per-cache directory under /sys/kernel/slab which hosts
> a bunch of debug files.  Usually, there aren't that many caches on a
> system and this doesn't really matter; however, if memcg is in use,
> each cache can have per-cgroup sub-caches.  SLUB creates the same
> directories for these sub-caches under /sys/kernel/slab/$CACHE/cgroup.
> 
> Unfortunately, because there can be a lot of cgroups, active or
> draining, the product of the numbers of caches, cgroups and files in
> each directory can reach a very high number - hundreds of thousands is
> commonplace.  Millions and beyond aren't difficult to reach either.
> 
> What's under /sys/kernel/slab is primarily for debugging and the
> information and control on the a root cache already cover its
> sub-caches.  While having a separate directory for each sub-cache can
> be helpful for development, it doesn't make much sense to pay this
> amount of overhead by default.
> 
> This patch introduces a boot parameter slub_memcg_sysfs which
> determines whether to create sysfs directories for per-memcg
> sub-caches.  It also adds CONFIG_SLUB_MEMCG_SYSFS_ON which determines
> the boot parameter's default value and defaults to 0.
> 
> ...
>
>  #ifdef CONFIG_MEMCG
> -	if (is_root_cache(s)) {
> +	if (is_root_cache(s) && memcg_sysfs_enabled) {

This could be turned on and off after bootup but I guess the result
could be pretty confusing.

However there would be useful use cases?  The user would normally have
this disabled but if he wants to do a bit of debugging then turn this
on, create a memcg, have a poke around then turn the feature off again.

>  		s->memcg_kset = kset_create_and_add("cgroup", NULL, &s->kobj);
>  		if (!s->memcg_kset) {
>  			err = -ENOMEM;
> @@ -5673,7 +5695,8 @@ static void sysfs_slab_remove(struct kme
>  		return;
>  
>  #ifdef CONFIG_MEMCG
> -	kset_unregister(s->memcg_kset);
> +	if (s->memcg_kset)
> +		kset_unregister(s->memcg_kset);

kset_unregister(NULL) is legal

--- a/mm/slub.c~slub-make-sysfs-directories-for-memcg-sub-caches-optional-fix
+++ a/mm/slub.c
@@ -5699,8 +5699,7 @@ static void sysfs_slab_remove(struct kme
 		return;
 
 #ifdef CONFIG_MEMCG
-	if (s->memcg_kset)
-		kset_unregister(s->memcg_kset);
+	kset_unregister(s->memcg_kset);
 #endif
 	kobject_uevent(&s->kobj, KOBJ_REMOVE);
 	kobject_del(&s->kobj);
_

--
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>

  reply	other threads:[~2017-02-07  0:22 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-04 14:52 [PATCH] slub: make sysfs directories for memcg sub-caches optional Tejun Heo
2017-02-04 14:52 ` Tejun Heo
2017-02-04 14:52 ` Tejun Heo
2017-02-07  0:22 ` Andrew Morton [this message]
2017-02-07  0:22   ` Andrew Morton
2017-02-07 17:10   ` Tejun Heo
2017-02-07 17:10     ` Tejun Heo
2017-02-07 17:10     ` Tejun Heo

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=20170206162213.30f909b5ce4c681e2217fb4f@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=cgroups@vger.kernel.org \
    --cc=cl@linux.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=kernel-team@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=penberg@kernel.org \
    --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: 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.