On 02/03/2014 02:05 PM, Glauber Costa wrote: > On Mon, Feb 3, 2014 at 10:57 AM, Vladimir Davydov > <vdavydov@xxxxxxxxxxxxx> wrote: >> On 02/03/2014 10:21 AM, David Rientjes wrote: >>> 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. >> AFAIU, cgroup identifiers dumped on oom (cgroup paths, currently) and >> memcg slab cache names serve for different purposes. The point is oom is >> a perfectly normal situation for the kernel, and info dumped to dmesg is >> for admin to find out the cause of the problem (a greedy user or >> cgroup). On the other hand, slab cache names are dumped to dmesg only on >> extraordinary situations - like bugs in slab implementation, or double >> free, or detected memory leaks - where we usually do not need the name >> of the memcg that triggered the problem, because the bug is likely to be >> in the kernel subsys using the cache. Plus, the names are exported to >> sysfs in case of slub, again for debugging purposes, AFAIK. So IMO the >> use cases for oom vs slab names are completely different - information >> vs debugging - and I want to export kmem.id only for the ability of >> debugging kmemcg and slab subsystems. >> > Then maybe it is better to wrap it into some kind of CONFIG_DEBUG wrap. > We already have other files like that. May be. However, kmemcg ids are actually exposed to userspace even on non-debug kernels (for instance, through /sys/kernel/slub), so I guess it's worth having this always enabled - the overhead of this is negligible anyway. Thanks. > >>> 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. >> Anyway, I agree with you that this needs a consensus, because this is a >> functional change. >> >> Thanks. > > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>