On Mon, 3 Dec 2012 17:24:08 +0400 Glauber Costa <glommer@xxxxxxxxxxxxx> wrote: > If memcg is tracking anything other than plain user memory (swap, tcp > buf mem, or slab memory), it is possible - and normal - that a reference > will be held by the group after it is dead. Still, for developers, it > would be extremely useful to be able to query about those states during > debugging. > > This patch provides a debugging facility in the root memcg, so we can > inspect which memcgs still have pending objects, and what is the cause > of this state. As this is a developer-only thing, I suggest that we should avoid burdening mainline with it. How about we maintain this in -mm (and hence in -next and mhocko's memcg tree) until we no longer see a need for it? > +config MEMCG_DEBUG_ASYNC_DESTROY > + bool "Memory Resource Controller Debug assynchronous object destruction" > + depends on MEMCG_KMEM || MEMCG_SWAP Could also depend on DEBUG_VM, I guess. > + default n > + help > + When a memcg is destroyed, the memory > + consumed by it may not be immediately freed. This is because when some > + extensions are used, such as swap or kernel memory, objects can > + outlive the group and hold a reference to it. > + > + If this is the case, the dangling_memcgs file will show information > + about what are the memcgs still alive, and which references are still > + preventing it to be freed. There is nothing wrong with that, but it is > + very useful when debugging, to know where this memory is being held. > + This is a developer-oriented debugging facility only, and no > + guarantees of interface stability will be given. > + fixlets: --- a/init/Kconfig~memcg-debugging-facility-to-access-dangling-memcgs-fix +++ a/init/Kconfig @@ -897,14 +897,14 @@ config MEMCG_KMEM will ever exhaust kernel resources alone. config MEMCG_DEBUG_ASYNC_DESTROY - bool "Memory Resource Controller Debug assynchronous object destruction" + bool "Memory Resource Controller Debug asynchronous object destruction" depends on MEMCG_KMEM || MEMCG_SWAP default n help - When a memcg is destroyed, the memory - consumed by it may not be immediately freed. This is because when some - extensions are used, such as swap or kernel memory, objects can - outlive the group and hold a reference to it. + When a memcg is destroyed, the memory consumed by it may not be + immediately freed. This is because when some extensions are used, such + as swap or kernel memory, objects can outlive the group and hold a + reference to it. If this is the case, the dangling_memcgs file will show information about what are the memcgs still alive, and which references are still _ -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
