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>
next prev parent 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: 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.