On Mon 03-02-14 10:57:03, Vladimir Davydov 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. I am really puzzled now. Why do you want to export the id/name then? If the source memcg is not relevant? I would understand if you tried to reduce your bug search place by the load which runs in the particular memcg. > > 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. I am for the full path same as we do when we dump oom information. This is much easier to consume. > 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> -- Michal Hocko SUSE Labs -- 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>