From: David Rientjes <rientjes@google.com>
To: Vladimir Davydov <vdavydov@parallels.com>
Cc: akpm@linux-foundation.org, mhocko@suse.cz, penberg@kernel.org,
cl@linux.com, glommer@gmail.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, devel@openvz.org
Subject: Re: [PATCH 1/8] memcg: export kmemcg cache id via cgroup fs
Date: Sun, 2 Feb 2014 22:21:28 -0800 (PST) [thread overview]
Message-ID: <alpine.DEB.2.02.1402022219101.10847@chino.kir.corp.google.com> (raw)
In-Reply-To: <570a97e4dfaded0939a9ddbea49055019dcc5803.1391356789.git.vdavydov@parallels.com>
On Sun, 2 Feb 2014, Vladimir Davydov wrote:
> Per-memcg kmem caches are named as follows:
>
> <global-cache-name>(<cgroup-kmem-id>:<cgroup-name>)
>
> where <cgroup-kmem-id> is the unique id of the memcg the cache belongs
> to, <cgroup-name> is the relative name of the memcg on the cgroup fs.
> Cache names are exposed to userspace for debugging purposes (e.g. via
> sysfs in case of slub or via dmesg).
>
> Using relative names makes it impossible in general (in case the cgroup
> hierarchy is not flat) to find out which memcg a particular cache
> belongs to, because <cgroup-kmem-id> is not known to the user. Since
> using absolute cgroup names would be an overkill, let's fix this by
> exporting the id of kmem-active memcg via cgroup fs file
> "memory.kmem.id".
>
Hmm, I'm not sure exporting additional information is the best way to do
it only for this purpose. I do understand the problem in naming
collisions if the hierarchy isn't flat and we typically work around that
by ensuring child memcgs still have a unique memcg. This isn't only a
problem in slab cache naming, me also avoid printing the entire absolute
names for things like the oom killer. So it would be nice to have
consensus on how people are supposed to identify memcgs with a hierarchy:
either by exporting information like the id like you do here (but leave
the oom killer still problematic) or by insisting people name their memcgs
with unique names if they care to differentiate them.
--
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:[~2014-02-03 6:21 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-02 16:33 [PATCH 0/8] memcg-vs-slab related fixes, improvements, cleanups Vladimir Davydov
2014-02-02 16:33 ` [PATCH 1/8] memcg: export kmemcg cache id via cgroup fs Vladimir Davydov
2014-02-03 6:21 ` David Rientjes [this message]
2014-02-03 6:57 ` Vladimir Davydov
2014-02-03 7:19 ` Vladimir Davydov
2014-02-03 10:05 ` Glauber Costa
2014-02-03 13:01 ` Vladimir Davydov
2014-02-03 11:04 ` David Rientjes
2014-02-03 13:00 ` Vladimir Davydov
2014-02-04 14:44 ` Michal Hocko
2014-02-04 14:40 ` Michal Hocko
2014-02-04 14:49 ` Vladimir Davydov
2014-02-02 16:33 ` [PATCH 2/8] memcg, slab: remove cgroup name from memcg cache names Vladimir Davydov
2014-02-04 14:45 ` Michal Hocko
2014-02-04 15:11 ` Vladimir Davydov
2014-02-04 15:13 ` Michal Hocko
2014-02-02 16:33 ` [PATCH 3/8] memcg, slab: never try to merge memcg caches Vladimir Davydov
2014-02-04 14:52 ` Michal Hocko
2014-02-04 14:59 ` Vladimir Davydov
2014-02-04 15:11 ` Michal Hocko
2014-02-04 15:27 ` Vladimir Davydov
2014-02-04 15:43 ` Glauber Costa
2014-02-04 16:04 ` Vladimir Davydov
2014-02-04 16:10 ` Glauber Costa
2014-02-06 14:07 ` Michal Hocko
2014-02-06 14:15 ` Vladimir Davydov
2014-02-06 15:29 ` Michal Hocko
2014-02-06 15:39 ` Vladimir Davydov
2014-02-02 16:33 ` [PATCH 4/8] memcg, slab: separate memcg vs root cache creation paths Vladimir Davydov
2014-02-02 16:33 ` [PATCH 5/8] slub: adjust memcg caches when creating cache alias Vladimir Davydov
2014-02-02 16:33 ` [PATCH 6/8] slub: rework sysfs layout for memcg caches Vladimir Davydov
2014-02-02 16:33 ` [PATCH 7/8] memcg, slab: unregister cache from memcg before starting to destroy it Vladimir Davydov
2014-02-02 16:33 ` [PATCH 8/8] memcg, slab: do not destroy children caches if parent has aliases Vladimir Davydov
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=alpine.DEB.2.02.1402022219101.10847@chino.kir.corp.google.com \
--to=rientjes@google.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=devel@openvz.org \
--cc=glommer@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.cz \
--cc=penberg@kernel.org \
--cc=vdavydov@parallels.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox