Re: [PATCH 01/10] slab/slub: struct memcg_params
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 >> Signed-off-by: Suleiman Souhlal >> CC: Christoph Lameter >> CC: Pekka Enberg >> CC: Michal Hocko >> CC: Kamezawa Hiroyuki >> CC: Johannes Weiner >> --- >> 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/
Re: [PATCH 01/10] slab/slub: struct memcg_params
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 > Signed-off-by: Suleiman Souhlal > CC: Christoph Lameter > CC: Pekka Enberg > CC: Michal Hocko > CC: Kamezawa Hiroyuki > CC: Johannes Weiner > --- > 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? -- Kirill A. Shutemov -- 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/
[PATCH 01/10] slab/slub: struct memcg_params
For the kmem slab controller, we need to record some extra information in the kmem_cache structure. Signed-off-by: Glauber Costa Signed-off-by: Suleiman Souhlal CC: Christoph Lameter CC: Pekka Enberg CC: Michal Hocko CC: Kamezawa Hiroyuki CC: Johannes Weiner --- 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; +}; +#endif + /* * Common kmalloc functions provided by all allocators */ diff --git a/include/linux/slab_def.h b/include/linux/slab_def.h index 0c634fa..39c5e9d 100644 --- a/include/linux/slab_def.h +++ b/include/linux/slab_def.h @@ -83,6 +83,10 @@ struct kmem_cache { int obj_offset; #endif /* CONFIG_DEBUG_SLAB */ +#ifdef CONFIG_MEMCG_KMEM + struct mem_cgroup_cache_params memcg_params; +#endif + /* 6) per-cpu/per-node data, touched during every alloc/free */ /* * We put array[] at the end of kmem_cache, because we want to size diff --git a/include/linux/slub_def.h b/include/linux/slub_def.h index df448ad..8bb8ad2 100644 --- a/include/linux/slub_def.h +++ b/include/linux/slub_def.h @@ -101,6 +101,9 @@ struct kmem_cache { #ifdef CONFIG_SYSFS struct kobject kobj;/* For sysfs */ #endif +#ifdef CONFIG_MEMCG_KMEM + struct mem_cgroup_cache_params memcg_params; +#endif #ifdef CONFIG_NUMA /* -- 1.7.10.4 -- 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/
Re: [PATCH 01/10] slab/slub: struct memcg_params
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? -- Kirill A. Shutemov -- 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/
Re: [PATCH 01/10] slab/slub: struct memcg_params
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/
[PATCH 01/10] slab/slub: struct memcg_params
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; +}; +#endif + /* * Common kmalloc functions provided by all allocators */ diff --git a/include/linux/slab_def.h b/include/linux/slab_def.h index 0c634fa..39c5e9d 100644 --- a/include/linux/slab_def.h +++ b/include/linux/slab_def.h @@ -83,6 +83,10 @@ struct kmem_cache { int obj_offset; #endif /* CONFIG_DEBUG_SLAB */ +#ifdef CONFIG_MEMCG_KMEM + struct mem_cgroup_cache_params memcg_params; +#endif + /* 6) per-cpu/per-node data, touched during every alloc/free */ /* * We put array[] at the end of kmem_cache, because we want to size diff --git a/include/linux/slub_def.h b/include/linux/slub_def.h index df448ad..8bb8ad2 100644 --- a/include/linux/slub_def.h +++ b/include/linux/slub_def.h @@ -101,6 +101,9 @@ struct kmem_cache { #ifdef CONFIG_SYSFS struct kobject kobj;/* For sysfs */ #endif +#ifdef CONFIG_MEMCG_KMEM + struct mem_cgroup_cache_params memcg_params; +#endif #ifdef CONFIG_NUMA /* -- 1.7.10.4 -- 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/