On 07/25/2012 11:26 PM, Kirill A. Shutemov wrote: > On Wed, Jul 25, 2012 at 06:38:12PM +0400, Glauber Costa wrote: >> For the kmem slab controller, we need to record some extra >> information in the kmem_cache structure. >> >> Signed-off-by: Glauber Costa <glom...@parallels.com> >> Signed-off-by: Suleiman Souhlal <sulei...@google.com> >> CC: Christoph Lameter <c...@linux.com> >> CC: Pekka Enberg <penb...@cs.helsinki.fi> >> CC: Michal Hocko <mho...@suse.cz> >> CC: Kamezawa Hiroyuki <kamezawa.hir...@jp.fujitsu.com> >> CC: Johannes Weiner <han...@cmpxchg.org> >> --- >> include/linux/slab.h | 7 +++++++ >> include/linux/slab_def.h | 4 ++++ >> include/linux/slub_def.h | 3 +++ >> 3 files changed, 14 insertions(+) >> >> diff --git a/include/linux/slab.h b/include/linux/slab.h >> index 0dd2dfa..3152bcd 100644 >> --- a/include/linux/slab.h >> +++ b/include/linux/slab.h >> @@ -177,6 +177,13 @@ unsigned int kmem_cache_size(struct kmem_cache *); >> #define ARCH_SLAB_MINALIGN __alignof__(unsigned long long) >> #endif >> >> +#ifdef CONFIG_MEMCG_KMEM >> +struct mem_cgroup_cache_params { >> + struct mem_cgroup *memcg; >> + int id; >> +}; > > IIUC, we only need the id to make slab name unique. Why can't we embed > the id to struct mem_cgroup? Is it possible to have multiple slabs with > the same combination of type, size, and memcg? > Humm, The id does not serve this purpose (perhaps deserves a comment here)
The purpose of the id is that given a slab, we can access it's memcg equivalent in constant time through the cache array in memcg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/