OpenVZ Forum - RDF feed
type: channel
items: [PATCH 00/10] memcg kmem limitation - slab.
items: [PATCH 01/10] slab/slub: struct memcg_params
items: [PATCH 02/10] consider a memcg parameter in kmem_create_cache
items: [PATCH 03/10] memcg: infrastructure to match an allocation to the right cache
items: [PATCH 04/10] memcg: skip memcg kmem allocations in specified code regions
items: [PATCH 05/10] slab: allow enable_cpu_cache to use preset values for its tunables
items: [PATCH 06/10] sl[au]b: Allocate objects from memcg cache
items: [PATCH 07/10] memcg: destroy memcg caches
items: [PATCH 08/10] memcg/sl[au]b Track all the memcg children of a kmem_cache.
items: [PATCH 09/10] slab: slab-specific propagation changes.
items: [PATCH 10/10] memcg/sl[au]b: shrink dead caches
items: Re: [PATCH 05/10] slab: allow enable_cpu_cache to use preset values for its tunables
items: Re: [PATCH 09/10] slab: slab-specific propagation changes.
items: Re: [PATCH 10/10] memcg/sl[au]b: shrink dead caches
items: Re: [PATCH 02/10] consider a memcg parameter in kmem_create_cache
items: Re: [PATCH 01/10] slab/slub: struct memcg_params
items: Re: [PATCH 03/10] memcg: infrastructure to match an allocation to the right cache
items: Re: [PATCH 04/10] memcg: skip memcg kmem allocations in specified code regions
items: Re: [PATCH 06/10] sl[au]b: Allocate objects from memcg cache
items: Re: [PATCH 00/10] memcg kmem limitation - slab.

[PATCH 00/10] memcg kmem limitation - slab.
type: item
description: Hi, This is the slab part of the kmem limitation mechanism in its last form. I would like to have comments on it to see if we can agree in its form. I consider it mature, since it doesn't change much in essence over the last forms. However, I would still prefer to defer merging it and merge the stack-only patchset first (even if inside the same merge window). That patchset contains most of the infrastructure needed here, and merging them separately would not only reduce the complexity for reviewers, but allow us a chance to have independent testing on them both. I would also likely benefit from some extra testing, to make sure the recent changes didn't introduce anything bad. A general explanation of what this is all about follows: The kernel memory limitation mechanism for memcg concerns itself with disallowing potentially non-reclaimable allocations to happen in exagerate quantities by a particular set of processes (cgroup). Those allocations could create pressure that affects the behavior of a different and unrelated set of processes. Its basic working mechanism is to annotate some allocations with the _GFP_KMEMCG flag. When this flag is set, the current process allocating will have its memcg identified and charged against. When reaching a specific limit, further allocations will be denied. One example of such problematic pressure that can be prevented by this work is a fork bomb conducted in a shell. We prevent it by noting that processes use a limited amount of stack pages. Seen this way, a fork bomb is just a special case of resource abuse. If the offender is unable to grab more pages for the stack, no new processes can be created. There are also other things the general mechanism protects against. For example, using too much of pinned dentry and inode cache, by touching files an leaving them in memory forever. In fact, a simple: while true; do mkdir x; cd x; done can halt your system easily, because the file system limits are hard to reach (big disks), but th…
creator: Glauber Costa
date: 2012-07-25T14:38:11-00:00

[PATCH 01/10] slab/slub: struct memcg_params
type: item
description: For the kmem slab controller, we need to record some extra information in the kmem_cache structure. Signed-off-by: Glauber Costa <glommer@parallels.com> Signed-off-by: Suleiman Souhlal <suleiman@google.com> CC: Christoph Lameter <cl@linux.com> CC: Pekka Enberg <penberg@cs.helsinki.fi> CC: Michal Hocko <mhocko@suse.cz> CC: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> CC: Johannes Weiner <hannes@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
creator: Glauber Costa
date: 2012-07-25T14:38:12-00:00

[PATCH 02/10] consider a memcg parameter in kmem_create_cache
type: item
description: Allow a memcg parameter to be passed during cache creation. When the slub allocator is being used, it will only merge caches that belong to the same memcg. Default function is created as a wrapper, passing NULL to the memcg version. We only merge caches that belong to the same memcg. >From the memcontrol.c side, 3 helper functions are created: 1) memcg_css_id: because slub needs a unique cache name for sysfs. Since this is visible, but not the canonical location for slab data, the cache name is not used, the css_id should suffice. 2) mem_cgroup_register_cache: is responsible for assigning a unique index to each cache, and other general purpose setup. The index is only assigned for the root caches. All others are assigned index == -1. 3) mem_cgroup_release_cache: can be called from the root cache destruction, and will release the index for other caches. We can't assign indexes until the basic slab is up and running this is because the ida subsystem will itself call slab functions such as kmalloc a couple of times. Because of that, we have a late_initcall that scan all caches and register them after the kernel is booted up. Only caches registered after that receive their index right away. This index mechanism was developed by Suleiman Souhlal. Changed to a idr/ida based approach based on suggestion from Kamezawa. Signed-off-by: Glauber Costa <glommer@parallels.com> CC: Christoph Lameter <cl@linux.com> CC: Pekka Enberg <penberg@cs.helsinki.fi> CC: Michal Hocko <mhocko@suse.cz> CC: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> CC: Johannes Weiner <hannes@cmpxchg.org> CC: Suleiman Souhlal <suleiman@google.com> --- include/linux/memcontrol.h | 14 ++++++++++++++ include/linux/slab.h | 10 ++++++++++ mm/memcontrol.c | 24 ++++++++++++++++++++++++ mm/slab.h | 24 ++++++++++++++++++++---- mm/slab_common.c | 36 +++++++++++++++++++++++++++++++----- mm/slub.c | 16 ++++++++++++---- 6 files changed, 111 insertions(+), 13 deletions(-) diff --git a/include/linux/memcontrol.h b/inc…
creator: Glauber Costa
date: 2012-07-25T14:38:13-00:00

[PATCH 03/10] memcg: infrastructure to match an allocation to the right cache
type: item
description: The page allocator is able to bind a page to a memcg when it is allocated. But for the caches, we'd like to have as many objects as possible in a page belonging to the same cache. This is done in this patch by calling memcg_kmem_get_cache in the beginning of every allocation function. This routing is patched out by static branches when kernel memory controller is not being used. It assumes that the task allocating, which determines the memcg in the page allocator, belongs to the same cgroup throughout the whole process. Misacounting can happen if the task calls memcg_kmem_get_cache() while belonging to a cgroup, and later on changes. This is considered acceptable, and should only happen upon task migration. Before the cache is created by the memcg core, there is also a possible imbalance: the task belongs to a memcg, but the cache being allocated from is the global cache, since the child cache is not yet guaranteed to be ready. This case is also fine, since in this case the GFP_KMEMCG will not be passed and the page allocator will not attempt any cgroup accounting. Signed-off-by: Glauber Costa <glommer@parallels.com> CC: Christoph Lameter <cl@linux.com> CC: Pekka Enberg <penberg@cs.helsinki.fi> CC: Michal Hocko <mhocko@suse.cz> CC: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> CC: Johannes Weiner <hannes@cmpxchg.org> CC: Suleiman Souhlal <suleiman@google.com> --- include/linux/memcontrol.h | 38 ++++++++ init/Kconfig | 2 +- mm/memcontrol.c | 221 +++++++++++++++++++++++++++++++++++++++++++- 3 files changed, 259 insertions(+), 2 deletions(-) diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h index d9229a3..bd1f34b 100644 --- a/include/linux/memcontrol.h +++ b/include/linux/memcontrol.h @@ -423,6 +423,8 @@ int memcg_css_id(struct mem_cgroup *memcg); void memcg_register_cache(struct mem_cgroup *memcg, struct kmem_cache *s); void memcg_release_cache(struct kmem_cache *cachep); +struct kmem_cache * +__memcg_kmem_get_cache(struct kmem_cache *cachep, g…
creator: Glauber Costa
date: 2012-07-25T14:38:14-00:00

[PATCH 04/10] memcg: skip memcg kmem allocations in specified code regions
type: item
description: This patch creates a mechanism that skip memcg allocations during certain pieces of our core code. It basically works in the same way as preempt_disable()/preempt_enable(): By marking a region under which all allocations will be accounted to the root memcg. We need this to prevent races in early cache creation, when we allocate data using caches that are not necessarily created already. Signed-off-by: Glauber Costa <glommer@parallels.com> CC: Christoph Lameter <cl@linux.com> CC: Pekka Enberg <penberg@cs.helsinki.fi> CC: Michal Hocko <mhocko@suse.cz> CC: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> CC: Johannes Weiner <hannes@cmpxchg.org> CC: Suleiman Souhlal <suleiman@google.com> --- include/linux/sched.h | 1 + mm/memcontrol.c | 27 +++++++++++++++++++++++++++ 2 files changed, 28 insertions(+) diff --git a/include/linux/sched.h b/include/linux/sched.h index c350e60..c09cd1b 100644 --- a/include/linux/sched.h +++ b/include/linux/sched.h @@ -1562,6 +1562,7 @@ struct task_struct { unsigned long nr_pages; /* uncharged usage */ unsigned long memsw_nr_pages; /* uncharged mem+swap usage */ } memcg_batch; + unsigned int memcg_kmem_skip_account; #endif #ifdef CONFIG_HAVE_HW_BREAKPOINT atomic_t ptrace_bp_refcnt; diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 8d012c7..854f6cc 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -541,6 +541,22 @@ static inline bool memcg_kmem_enabled(struct mem_cgroup *memcg) memcg->kmem_accounted; } +static void memcg_stop_kmem_account(void) +{ + if (!current->mm) + return; + + current->memcg_kmem_skip_account++; +} + +static void memcg_resume_kmem_account(void) +{ + if (!current->mm) + return; + + current->memcg_kmem_skip_account--; +} + static char *memcg_cache_name(struct mem_cgroup *memcg, struct kmem_cache *cachep) { char *name; @@ -614,6 +630,10 @@ bool __memcg_kmem_new_page(gfp_t gfp, void *_handle, int order) struct task_struct *p; *handle = NULL; + + if (current->memcg_kmem_skip_account) + return true; + rcu_read_lock(); p…
creator: Glauber Costa
date: 2012-07-25T14:38:15-00:00

[PATCH 05/10] slab: allow enable_cpu_cache to use preset values for its tunables
type: item
description: SLAB allows us to tune a particular cache behavior with tunables. When creating a new memcg cache copy, we'd like to preserve any tunables the parent cache already had. This could be done by an explicit call to do_tune_cpucache() after the cache is created. But this is not very convenient now that the caches are created from common code, since this function is SLAB-specific. Another method of doing that is taking advantage of the fact that do_tune_cpucache() is always called from enable_cpucache(), which is called at cache initialization. We can just preset the values, and then things work as expected. Signed-off-by: Glauber Costa <glommer@parallels.com> CC: Christoph Lameter <cl@linux.com> CC: Pekka Enberg <penberg@cs.helsinki.fi> CC: Michal Hocko <mhocko@suse.cz> CC: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> CC: Johannes Weiner <hannes@cmpxchg.org> CC: Suleiman Souhlal <suleiman@google.com> --- include/linux/slab.h | 3 ++- mm/memcontrol.c | 2 +- mm/slab.c | 19 ++++++++++++++++--- mm/slab_common.c | 7 ++++--- 4 files changed, 23 insertions(+), 8 deletions(-) diff --git a/include/linux/slab.h b/include/linux/slab.h index 9d3fd56..249a0d3 100644 --- a/include/linux/slab.h +++ b/include/linux/slab.h @@ -128,7 +128,7 @@ struct kmem_cache *kmem_cache_create(const char *, size_t, size_t, void (*)(void *)); struct kmem_cache * kmem_cache_create_memcg(struct mem_cgroup *, const char *, size_t, size_t, - unsigned long, void (*)(void *)); + unsigned long, void (*)(void *), struct kmem_cache *); void kmem_cache_destroy(struct kmem_cache *); int kmem_cache_shrink(struct kmem_cache *); void kmem_cache_free(struct kmem_cache *, void *); @@ -184,6 +184,7 @@ unsigned int kmem_cache_size(struct kmem_cache *); #ifdef CONFIG_MEMCG_KMEM struct mem_cgroup_cache_params { struct mem_cgroup *memcg; + struct kmem_cache *parent; int id; }; #endif diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 854f6cc..b933474 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -585,7 +585,7…
creator: Glauber Costa
date: 2012-07-25T14:38:16-00:00

[PATCH 06/10] sl[au]b: Allocate objects from memcg cache
type: item
description: We are able to match a cache allocation to a particular memcg. If the task doesn't change groups during the allocation itself - a rare event, this will give us a good picture about who is the first group to touch a cache page. This patch uses the now available infrastructure by calling memcg_kmem_get_cache() before all the cache allocations. Signed-off-by: Glauber Costa <glommer@parallels.com> CC: Christoph Lameter <cl@linux.com> CC: Pekka Enberg <penberg@cs.helsinki.fi> CC: Michal Hocko <mhocko@suse.cz> CC: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> CC: Johannes Weiner <hannes@cmpxchg.org> CC: Suleiman Souhlal <suleiman@google.com> --- include/linux/slub_def.h | 18 +++++++++++++----- mm/memcontrol.c | 2 ++ mm/slab.c | 4 ++++ mm/slub.c | 1 + 4 files changed, 20 insertions(+), 5 deletions(-) diff --git a/include/linux/slub_def.h b/include/linux/slub_def.h index 8bb8ad2..148000a 100644 --- a/include/linux/slub_def.h +++ b/include/linux/slub_def.h @@ -13,6 +13,8 @@ #include <linux/kobject.h> #include <linux/kmemleak.h> +#include <linux/memcontrol.h> +#include <linux/mm.h> enum stat_item { ALLOC_FASTPATH, /* Allocation from cpu slab */ @@ -209,14 +211,14 @@ static __always_inline int kmalloc_index(size_t size) * This ought to end up with a global pointer to the right cache * in kmalloc_caches. */ -static __always_inline struct kmem_cache *kmalloc_slab(size_t size) +static __always_inline struct kmem_cache *kmalloc_slab(gfp_t flags, size_t size) { int index = kmalloc_index(size); if (index == 0) return NULL; - return kmalloc_caches[index]; + return memcg_kmem_get_cache(kmalloc_caches[index], flags); } void *kmem_cache_alloc(struct kmem_cache *, gfp_t); @@ -225,7 +227,13 @@ void *__kmalloc(size_t size, gfp_t flags); static __always_inline void * kmalloc_order(size_t size, gfp_t flags, unsigned int order) { - void *ret = (void *) __get_free_pages(flags | __GFP_COMP, order); + void *ret; + + flags = __GFP_COMP; +#ifdef CONFIG_MEMCG_KMEM + flags |= __GFP_KMEMCG; +#en…
creator: Glauber Costa
date: 2012-07-25T14:38:17-00:00

[PATCH 07/10] memcg: destroy memcg caches
type: item
description: This patch implements destruction of memcg caches. Right now, only caches where our reference counter is the last remaining are deleted. If there are any other reference counters around, we just leave the caches lying around until they go away. When that happen, a destruction function is called from the cache code. Caches are only destroyed in process context, so we queue them up for later processing in the general case. Signed-off-by: Glauber Costa <glommer@parallels.com> CC: Christoph Lameter <cl@linux.com> CC: Pekka Enberg <penberg@cs.helsinki.fi> CC: Michal Hocko <mhocko@suse.cz> CC: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> CC: Johannes Weiner <hannes@cmpxchg.org> CC: Suleiman Souhlal <suleiman@google.com> --- include/linux/memcontrol.h | 1 + include/linux/slab.h | 3 ++ mm/memcontrol.c | 84 ++++++++++++++++++++++++++++++++++++++++++++ mm/slab.c | 4 +++ mm/slab.h | 21 +++++++++++ mm/slub.c | 7 +++- 6 files changed, 119 insertions(+), 1 deletion(-) diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h index bd1f34b..247019f 100644 --- a/include/linux/memcontrol.h +++ b/include/linux/memcontrol.h @@ -425,6 +425,7 @@ void memcg_register_cache(struct mem_cgroup *memcg, void memcg_release_cache(struct kmem_cache *cachep); struct kmem_cache * __memcg_kmem_get_cache(struct kmem_cache *cachep, gfp_t gfp); +void mem_cgroup_destroy_cache(struct kmem_cache *cachep); #else static inline void memcg_register_cache(struct mem_cgroup *memcg, struct kmem_cache *s) diff --git a/include/linux/slab.h b/include/linux/slab.h index 249a0d3..b9310a4 100644 --- a/include/linux/slab.h +++ b/include/linux/slab.h @@ -186,6 +186,9 @@ struct mem_cgroup_cache_params { struct mem_cgroup *memcg; struct kmem_cache *parent; int id; + bool dead; + atomic_t nr_pages; + struct list_head destroyed_list; /* Used when deleting memcg cache */ }; #endif diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 2cc3acf..1231d86 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -599,…
creator: Glauber Costa
date: 2012-07-25T14:38:18-00:00

[PATCH 08/10] memcg/sl[au]b Track all the memcg children of a kmem_cache.
type: item
description: This enables us to remove all the children of a kmem_cache being destroyed, if for example the kernel module it's being used in gets unloaded. Otherwise, the children will still point to the destroyed parent. Signed-off-by: Suleiman Souhlal <suleiman@google.com> Signed-off-by: Glauber Costa <glommer@parallels.com> CC: Christoph Lameter <cl@linux.com> CC: Pekka Enberg <penberg@cs.helsinki.fi> CC: Michal Hocko <mhocko@suse.cz> CC: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> CC: Johannes Weiner <hannes@cmpxchg.org> --- include/linux/memcontrol.h | 1 + include/linux/slab.h | 1 + mm/memcontrol.c | 16 +++++++++++++++- mm/slab_common.c | 31 +++++++++++++++++++++++++++++++ 4 files changed, 48 insertions(+), 1 deletion(-) diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h index 247019f..f8d63f2 100644 --- a/include/linux/memcontrol.h +++ b/include/linux/memcontrol.h @@ -426,6 +426,7 @@ void memcg_release_cache(struct kmem_cache *cachep); struct kmem_cache * __memcg_kmem_get_cache(struct kmem_cache *cachep, gfp_t gfp); void mem_cgroup_destroy_cache(struct kmem_cache *cachep); +void mem_cgroup_remove_child_kmem_cache(struct kmem_cache *cachep, int id); #else static inline void memcg_register_cache(struct mem_cgroup *memcg, struct kmem_cache *s) diff --git a/include/linux/slab.h b/include/linux/slab.h index b9310a4..3cfd784 100644 --- a/include/linux/slab.h +++ b/include/linux/slab.h @@ -189,6 +189,7 @@ struct mem_cgroup_cache_params { bool dead; atomic_t nr_pages; struct list_head destroyed_list; /* Used when deleting memcg cache */ + struct list_head sibling_list; }; #endif diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 1231d86..d92d963 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -586,8 +586,11 @@ static struct kmem_cache *kmem_cache_dup(struct mem_cgroup *memcg, new = kmem_cache_create_memcg(memcg, name, s->object_size, s->align, (s->flags & ~SLAB_PANIC), s->ctor, s); - if (new) + if (new) { new->allocflags |= __GFP_KMEMCG; + list_add…
creator: Glauber Costa
date: 2012-07-25T14:38:19-00:00

[PATCH 09/10] slab: slab-specific propagation changes.
type: item
description: When a parent cache does tune_cpucache, we need to propagate that to the children as well. For that, we unfortunately need to tap into the slab core. Signed-off-by: Glauber Costa <glommer@parallels.com> CC: Christoph Lameter <cl@linux.com> CC: Pekka Enberg <penberg@cs.helsinki.fi> CC: Michal Hocko <mhocko@suse.cz> CC: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> CC: Johannes Weiner <hannes@cmpxchg.org> CC: Suleiman Souhlal <suleiman@google.com> --- mm/slab.c | 28 +++++++++++++++++++++++++++- mm/slab_common.c | 1 + 2 files changed, 28 insertions(+), 1 deletion(-) diff --git a/mm/slab.c b/mm/slab.c index 21d7cf7..6d8d449 100644 --- a/mm/slab.c +++ b/mm/slab.c @@ -3877,7 +3877,7 @@ static void do_ccupdate_local(void *info) } /* Always called with the slab_mutex held */ -static int do_tune_cpucache(struct kmem_cache *cachep, int limit, +static int __do_tune_cpucache(struct kmem_cache *cachep, int limit, int batchcount, int shared, gfp_t gfp) { struct ccupdate_struct *new; @@ -3920,6 +3920,32 @@ static int do_tune_cpucache(struct kmem_cache *cachep, int limit, return alloc_kmemlist(cachep, gfp); } +static int do_tune_cpucache(struct kmem_cache *cachep, int limit, + int batchcount, int shared, gfp_t gfp) +{ + int ret; +#ifdef CONFIG_MEMCG_KMEM + struct kmem_cache *c; + struct mem_cgroup_cache_params *p; +#endif + + ret = __do_tune_cpucache(cachep, limit, batchcount, shared, gfp); +#ifdef CONFIG_MEMCG_KMEM + if (slab_state < FULL) + return ret; + + if ((ret < 0) || (cachep->memcg_params.id == -1)) + return ret; + + list_for_each_entry(p, &cachep->memcg_params.sibling_list, sibling_list) { + c = container_of(p, struct kmem_cache, memcg_params); + /* return value determined by the parent cache only */ + __do_tune_cpucache(c, limit, batchcount, shared, gfp); + } +#endif + return ret; +} + /* Called with slab_mutex held always */ static int enable_cpucache(struct kmem_cache *cachep, gfp_t gfp) { diff --git a/mm/slab_common.c b/mm/slab_common.c index 6504557..e340a7d 1006…
creator: Glauber Costa
date: 2012-07-25T14:38:20-00:00

[PATCH 10/10] memcg/sl[au]b: shrink dead caches
type: item
description: In the slub allocator, when the last object of a page goes away, we don't necessarily free it - there is not necessarily a test for empty page in any slab_free path. This means that when we destroy a memcg cache that happened to be empty, those caches may take a lot of time to go away: removing the memcg reference won't destroy them - because there are pending references, and the empty pages will stay there, until a shrinker is called upon for any reason. This patch marks all memcg caches as dead. kmem_cache_shrink is called for the ones who are not yet dead - this will force internal cache reorganization, and then all references to empty pages will be removed. An unlikely branch is used to make sure this case does not affect performance in the usual slab_free path. The slab allocator has a time based reaper that would eventually get rid of the objects, but we can also call it explicitly, since dead caches are not a likely event. [ v2: also call verify_dead for the slab ] Signed-off-by: Glauber Costa <glommer@parallels.com> CC: Christoph Lameter <cl@linux.com> CC: Pekka Enberg <penberg@cs.helsinki.fi> CC: Michal Hocko <mhocko@suse.cz> CC: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> CC: Johannes Weiner <hannes@cmpxchg.org> CC: Suleiman Souhlal <suleiman@google.com> --- include/linux/slab.h | 3 +++ mm/memcontrol.c | 44 +++++++++++++++++++++++++++++++++++++++++++- mm/slab.c | 2 ++ mm/slab.h | 10 ++++++++++ mm/slub.c | 1 + 5 files changed, 59 insertions(+), 1 deletion(-) diff --git a/include/linux/slab.h b/include/linux/slab.h index 3cfd784..6ca9ccb 100644 --- a/include/linux/slab.h +++ b/include/linux/slab.h @@ -182,6 +182,8 @@ unsigned int kmem_cache_size(struct kmem_cache *); #endif #ifdef CONFIG_MEMCG_KMEM +#include <linux/workqueue.h> + struct mem_cgroup_cache_params { struct mem_cgroup *memcg; struct kmem_cache *parent; @@ -190,6 +192,7 @@ struct mem_cgroup_cache_params { atomic_t nr_pages; struct list_head destroyed_list; /* Used when deleting memcg cache …
creator: Glauber Costa
date: 2012-07-25T14:38:21-00:00

Re: [PATCH 05/10] slab: allow enable_cpu_cache to use preset values for its tunables
type: item
description: On Wed, 25 Jul 2012, Glauber Costa wrote: > SLAB allows us to tune a particular cache behavior with tunables. > When creating a new memcg cache copy, we'd like to preserve any tunables > the parent cache already had. So does SLUB but I do not see a patch for that allocator.
creator: Christoph Lameter
date: 2012-07-25T17:05:28-00:00

Re: [PATCH 09/10] slab: slab-specific propagation changes.
type: item
description: On Wed, 25 Jul 2012, Glauber Costa wrote: > When a parent cache does tune_cpucache, we need to propagate that to the > children as well. For that, we unfortunately need to tap into the slab core. Slub also has tunables.
creator: Christoph Lameter
date: 2012-07-25T17:07:00-00:00

Re: [PATCH 10/10] memcg/sl[au]b: shrink dead caches
type: item
description: On Wed, 25 Jul 2012, Glauber Costa wrote: > In the slub allocator, when the last object of a page goes away, we > don't necessarily free it - there is not necessarily a test for empty > page in any slab_free path. That is true for the slab allocator as well. In either case calling kmem_cache_shrink() will make the objects go away by draining the cached objects and freeing the pages used for the objects back to the page allocator. You do not need this patch. Just call the proper functions to drop the objecgts in the caches in either allocator. > The slab allocator has a time based reaper that would eventually get rid > of the objects, but we can also call it explicitly, since dead caches > are not a likely event. So this is already for both allocators?
creator: Christoph Lameter
date: 2012-07-25T17:13:23-00:00

Re: [PATCH 02/10] consider a memcg parameter in kmem_create_cache
type: item
description: On Wed, Jul 25, 2012 at 06:38:13PM +0400, Glauber Costa wrote: ... > @@ -337,6 +341,12 @@ extern void *__kmalloc_track_caller(size_t, gfp_t, unsigned long); > __kmalloc(size, flags) > #endif /* DEBUG_SLAB */ > > +#ifdef CONFIG_MEMCG_KMEM > +#define MAX_KMEM_CACHE_TYPES 400 > +#else > +#define MAX_KMEM_CACHE_TYPES 0 > +#endif /* CONFIG_MEMCG_KMEM */ > + > #ifdef CONFIG_NUMA > /* > * kmalloc_node_track_caller is a special version of kmalloc_node that ... > @@ -527,6 +532,24 @@ static inline bool memcg_kmem_enabled(struct mem_cgroup *memcg) > memcg->kmem_accounted; > } > > +struct ida cache_types; > + > +void memcg_register_cache(struct mem_cgroup *memcg, struct kmem_cache *cachep) > +{ > + int id = -1; > + > + if (!memcg) > + id = ida_simple_get(&cache_types, 0, MAX_KMEM_CACHE_TYPES, > + GFP_KERNEL); MAX_KMEM_CACHE_TYPES is 0 if CONFIG_MEMCG_KMEM undefined. If 'end' parameter of ida_simple_get() is 0 it will use default max value which is 0x80000000. I guess you want MAX_KMEM_CACHE_TYPES to be 1 for !CONFIG_MEMCG_KMEM. -- Kirill A. Shutemov
creator: Kirill A. Shutsemov
date: 2012-07-25T18:10:13-00:00

Re: [PATCH 10/10] memcg/sl[au]b: shrink dead caches
type: item
description: On 07/25/2012 09:13 PM, Christoph Lameter wrote: > On Wed, 25 Jul 2012, Glauber Costa wrote: > >> In the slub allocator, when the last object of a page goes away, we >> don't necessarily free it - there is not necessarily a test for empty >> page in any slab_free path. > > That is true for the slab allocator as well. In either case calling > kmem_cache_shrink() will make the objects go away by draining the cached > objects and freeing the pages used for the objects back to the page > allocator. You do not need this patch. Just call the proper functions to > drop the objecgts in the caches in either allocator. > >> The slab allocator has a time based reaper that would eventually get rid >> of the objects, but we can also call it explicitly, since dead caches >> are not a likely event. > > So this is already for both allocators? > Yes, I just didn't updated the whole changelog. my bad.
creator: Glauber Costa
date: 2012-07-25T18:16:34-00:00

Re: [PATCH 05/10] slab: allow enable_cpu_cache to use preset values for its tunables
type: item
description: On 07/25/2012 09:05 PM, Christoph Lameter wrote: > On Wed, 25 Jul 2012, Glauber Costa wrote: > >> SLAB allows us to tune a particular cache behavior with tunables. >> When creating a new memcg cache copy, we'd like to preserve any tunables >> the parent cache already had. > > So does SLUB but I do not see a patch for that allocator. > It is certainly not through does the same method as SLAB, right ? Writing to /proc/slabinfo gives me an I/O error I assume it is something through sysfs, but schiming through the code now, I can't find any per-cache tunables. Would you mind pointing me to them? In any case, are you happy with the SLAB one, and how they are propagated?
creator: Glauber Costa
date: 2012-07-25T18:24:57-00:00

Re: [PATCH 05/10] slab: allow enable_cpu_cache to use preset values for its tunables
type: item
description: On Wed, 25 Jul 2012, Glauber Costa wrote: > It is certainly not through does the same method as SLAB, right ? > Writing to /proc/slabinfo gives me an I/O error > I assume it is something through sysfs, but schiming through the code > now, I can't find any per-cache tunables. Would you mind pointing me to > them? The slab attributes in /sys/kernel/slab/<slabname>/<attr> can be modified for some values. I think that could be the default method for the future since it allows easy addition of new tunables as needed.
creator: Christoph Lameter
date: 2012-07-25T18:33:16-00:00

Re: [PATCH 01/10] slab/slub: struct memcg_params
type: item
description: 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 <glommer@parallels.com> >> Signed-off-by: Suleiman Souhlal <suleiman@google.com> >> CC: Christoph Lameter <cl@linux.com> >> CC: Pekka Enberg <penberg@cs.helsinki.fi> >> CC: Michal Hocko <mhocko@suse.cz> >> CC: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> >> CC: Johannes Weiner <hannes@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.
creator: Glauber Costa
date: 2012-07-25T19:25:31-00:00

Re: [PATCH 01/10] slab/slub: struct memcg_params
type: item
description: 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 <glommer@parallels.com> > Signed-off-by: Suleiman Souhlal <suleiman@google.com> > CC: Christoph Lameter <cl@linux.com> > CC: Pekka Enberg <penberg@cs.helsinki.fi> > CC: Michal Hocko <mhocko@suse.cz> > CC: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> > CC: Johannes Weiner <hannes@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
creator: Kirill A. Shutsemov
date: 2012-07-25T19:26:39-00:00

Re: [PATCH 03/10] memcg: infrastructure to match an allocation to the right cache
type: item
description: On Wed, Jul 25, 2012 at 06:38:14PM +0400, Glauber Costa wrote: > The page allocator is able to bind a page to a memcg when it is > allocated. But for the caches, we'd like to have as many objects as > possible in a page belonging to the same cache. > > This is done in this patch by calling memcg_kmem_get_cache in the > beginning of every allocation function. This routing is patched out by > static branches when kernel memory controller is not being used. > > It assumes that the task allocating, which determines the memcg in the > page allocator, belongs to the same cgroup throughout the whole process. > Misacounting can happen if the task calls memcg_kmem_get_cache() while > belonging to a cgroup, and later on changes. This is considered > acceptable, and should only happen upon task migration. > > Before the cache is created by the memcg core, there is also a possible > imbalance: the task belongs to a memcg, but the cache being allocated > from is the global cache, since the child cache is not yet guaranteed to > be ready. This case is also fine, since in this case the GFP_KMEMCG will > not be passed and the page allocator will not attempt any cgroup > accounting. > > Signed-off-by: Glauber Costa <glommer@parallels.com> > CC: Christoph Lameter <cl@linux.com> > CC: Pekka Enberg <penberg@cs.helsinki.fi> > CC: Michal Hocko <mhocko@suse.cz> > CC: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> > CC: Johannes Weiner <hannes@cmpxchg.org> > CC: Suleiman Souhlal <suleiman@google.com> > --- > include/linux/memcontrol.h | 38 ++++++++ > init/Kconfig | 2 +- > mm/memcontrol.c | 221 +++++++++++++++++++++++++++++++++++++++++++- > 3 files changed, 259 insertions(+), 2 deletions(-) > > diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h > index d9229a3..bd1f34b 100644 > --- a/include/linux/memcontrol.h > +++ b/include/linux/memcontrol.h > @@ -423,6 +423,8 @@ int memcg_css_id(struct mem_cgroup *memcg); > void memcg_register_cache(struct mem_cgroup *memcg, > stru…
creator: Kirill A. Shutsemov
date: 2012-07-25T21:53:32-00:00

Re: [PATCH 02/10] consider a memcg parameter in kmem_create_cache
type: item
description: On 07/25/2012 10:10 PM, Kirill A. Shutemov wrote: > On Wed, Jul 25, 2012 at 06:38:13PM +0400, Glauber Costa wrote: > > ... > >> @@ -337,6 +341,12 @@ extern void *__kmalloc_track_caller(size_t, gfp_t, unsigned long); >> __kmalloc(size, flags) >> #endif /* DEBUG_SLAB */ >> >> +#ifdef CONFIG_MEMCG_KMEM >> +#define MAX_KMEM_CACHE_TYPES 400 >> +#else >> +#define MAX_KMEM_CACHE_TYPES 0 >> +#endif /* CONFIG_MEMCG_KMEM */ >> + >> #ifdef CONFIG_NUMA >> /* >> * kmalloc_node_track_caller is a special version of kmalloc_node that > > ... > >> @@ -527,6 +532,24 @@ static inline bool memcg_kmem_enabled(struct mem_cgroup *memcg) >> memcg->kmem_accounted; >> } >> >> +struct ida cache_types; >> + >> +void memcg_register_cache(struct mem_cgroup *memcg, struct kmem_cache *cachep) >> +{ >> + int id = -1; >> + >> + if (!memcg) >> + id = ida_simple_get(&cache_types, 0, MAX_KMEM_CACHE_TYPES, >> + GFP_KERNEL); > > MAX_KMEM_CACHE_TYPES is 0 if CONFIG_MEMCG_KMEM undefined. > If 'end' parameter of ida_simple_get() is 0 it will use default max value > which is 0x80000000. > I guess you want MAX_KMEM_CACHE_TYPES to be 1 for !CONFIG_MEMCG_KMEM. > ida_simple_get will not, and should never be called for !CONFIG_MEMCG_KMEM.
creator: Glauber Costa
date: 2012-07-26T09:42:05-00:00

Re: [PATCH 02/10] consider a memcg parameter in kmem_create_cache
type: item
description: On Thu, Jul 26, 2012 at 01:42:05PM +0400, Glauber Costa wrote: > On 07/25/2012 10:10 PM, Kirill A. Shutemov wrote: > > On Wed, Jul 25, 2012 at 06:38:13PM +0400, Glauber Costa wrote: > > > > ... > > > >> @@ -337,6 +341,12 @@ extern void *__kmalloc_track_caller(size_t, gfp_t, unsigned long); > >> __kmalloc(size, flags) > >> #endif /* DEBUG_SLAB */ > >> > >> +#ifdef CONFIG_MEMCG_KMEM > >> +#define MAX_KMEM_CACHE_TYPES 400 > >> +#else > >> +#define MAX_KMEM_CACHE_TYPES 0 > >> +#endif /* CONFIG_MEMCG_KMEM */ > >> + > >> #ifdef CONFIG_NUMA > >> /* > >> * kmalloc_node_track_caller is a special version of kmalloc_node that > > > > ... > > > >> @@ -527,6 +532,24 @@ static inline bool memcg_kmem_enabled(struct mem_cgroup *memcg) > >> memcg->kmem_accounted; > >> } > >> > >> +struct ida cache_types; > >> + > >> +void memcg_register_cache(struct mem_cgroup *memcg, struct kmem_cache *cachep) > >> +{ > >> + int id = -1; > >> + > >> + if (!memcg) > >> + id = ida_simple_get(&cache_types, 0, MAX_KMEM_CACHE_TYPES, > >> + GFP_KERNEL); > > > > MAX_KMEM_CACHE_TYPES is 0 if CONFIG_MEMCG_KMEM undefined. > > If 'end' parameter of ida_simple_get() is 0 it will use default max value > > which is 0x80000000. > > I guess you want MAX_KMEM_CACHE_TYPES to be 1 for !CONFIG_MEMCG_KMEM. > > > ida_simple_get will not, and should never be called for !CONFIG_MEMCG_KMEM. Okay. Is there an user for MAX_KMEM_CACHE_TYPES if !CONFIG_MEMCG_KMEM? -- Kirill A. Shutemov
creator: Kirill A. Shutsemov
date: 2012-07-26T10:01:08-00:00

Re: [PATCH 02/10] consider a memcg parameter in kmem_create_cache
type: item
description: On 07/26/2012 02:01 PM, Kirill A. Shutemov wrote: > On Thu, Jul 26, 2012 at 01:42:05PM +0400, Glauber Costa wrote: >> On 07/25/2012 10:10 PM, Kirill A. Shutemov wrote: >>> On Wed, Jul 25, 2012 at 06:38:13PM +0400, Glauber Costa wrote: >>> >>> ... >>> >>>> @@ -337,6 +341,12 @@ extern void *__kmalloc_track_caller(size_t, gfp_t, unsigned long); >>>> __kmalloc(size, flags) >>>> #endif /* DEBUG_SLAB */ >>>> >>>> +#ifdef CONFIG_MEMCG_KMEM >>>> +#define MAX_KMEM_CACHE_TYPES 400 >>>> +#else >>>> +#define MAX_KMEM_CACHE_TYPES 0 >>>> +#endif /* CONFIG_MEMCG_KMEM */ >>>> + >>>> #ifdef CONFIG_NUMA >>>> /* >>>> * kmalloc_node_track_caller is a special version of kmalloc_node that >>> >>> ... >>> >>>> @@ -527,6 +532,24 @@ static inline bool memcg_kmem_enabled(struct mem_cgroup *memcg) >>>> memcg->kmem_accounted; >>>> } >>>> >>>> +struct ida cache_types; >>>> + >>>> +void memcg_register_cache(struct mem_cgroup *memcg, struct kmem_cache *cachep) >>>> +{ >>>> + int id = -1; >>>> + >>>> + if (!memcg) >>>> + id = ida_simple_get(&cache_types, 0, MAX_KMEM_CACHE_TYPES, >>>> + GFP_KERNEL); >>> >>> MAX_KMEM_CACHE_TYPES is 0 if CONFIG_MEMCG_KMEM undefined. >>> If 'end' parameter of ida_simple_get() is 0 it will use default max value >>> which is 0x80000000. >>> I guess you want MAX_KMEM_CACHE_TYPES to be 1 for !CONFIG_MEMCG_KMEM. >>> >> ida_simple_get will not, and should never be called for !CONFIG_MEMCG_KMEM. > > Okay. Is there an user for MAX_KMEM_CACHE_TYPES if !CONFIG_MEMCG_KMEM? > Actually, not anymore. I will just remove it then, instead of forcing it to 0. Thanks!
creator: Glauber Costa
date: 2012-07-26T10:27:15-00:00

Re: [PATCH 05/10] slab: allow enable_cpu_cache to use preset values for its tunables
type: item
description: On 07/25/2012 10:33 PM, Christoph Lameter wrote: > On Wed, 25 Jul 2012, Glauber Costa wrote: > >> It is certainly not through does the same method as SLAB, right ? >> Writing to /proc/slabinfo gives me an I/O error >> I assume it is something through sysfs, but schiming through the code >> now, I can't find any per-cache tunables. Would you mind pointing me to >> them? > > The slab attributes in /sys/kernel/slab/<slabname>/<attr> can be modified > for some values. I think that could be the default method for the future > since it allows easy addition of new tunables as needed. > Christoph, would the following PoC patch be enough?
creator: Glauber Costa
date: 2012-07-26T14:02:45-00:00

Re: [PATCH 04/10] memcg: skip memcg kmem allocations in specified code regions
type: item
description: On Wed, Jul 25, 2012 at 06:38:15PM +0400, Glauber Costa wrote: > This patch creates a mechanism that skip memcg allocations during > certain pieces of our core code. It basically works in the same way > as preempt_disable()/preempt_enable(): By marking a region under > which all allocations will be accounted to the root memcg. > > We need this to prevent races in early cache creation, when we > allocate data using caches that are not necessarily created already. Why not a GFP_* flag? -- Kirill A. Shutemov
creator: Kirill A. Shutsemov
date: 2012-07-30T12:49:50-00:00

Re: [PATCH 06/10] sl[au]b: Allocate objects from memcg cache
type: item
description: On Wed, Jul 25, 2012 at 06:38:17PM +0400, Glauber Costa wrote: > We are able to match a cache allocation to a particular memcg. If the > task doesn't change groups during the allocation itself - a rare event, > this will give us a good picture about who is the first group to touch a > cache page. > > This patch uses the now available infrastructure by calling > memcg_kmem_get_cache() before all the cache allocations. > > Signed-off-by: Glauber Costa <glommer@parallels.com> > CC: Christoph Lameter <cl@linux.com> > CC: Pekka Enberg <penberg@cs.helsinki.fi> > CC: Michal Hocko <mhocko@suse.cz> > CC: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> > CC: Johannes Weiner <hannes@cmpxchg.org> > CC: Suleiman Souhlal <suleiman@google.com> > --- > include/linux/slub_def.h | 18 +++++++++++++----- > mm/memcontrol.c | 2 ++ > mm/slab.c | 4 ++++ > mm/slub.c | 1 + > 4 files changed, 20 insertions(+), 5 deletions(-) > > diff --git a/include/linux/slub_def.h b/include/linux/slub_def.h > index 8bb8ad2..148000a 100644 > --- a/include/linux/slub_def.h > +++ b/include/linux/slub_def.h > @@ -13,6 +13,8 @@ > #include <linux/kobject.h> > > #include <linux/kmemleak.h> > +#include <linux/memcontrol.h> > +#include <linux/mm.h> > > enum stat_item { > ALLOC_FASTPATH, /* Allocation from cpu slab */ > @@ -209,14 +211,14 @@ static __always_inline int kmalloc_index(size_t size) > * This ought to end up with a global pointer to the right cache > * in kmalloc_caches. > */ > -static __always_inline struct kmem_cache *kmalloc_slab(size_t size) > +static __always_inline struct kmem_cache *kmalloc_slab(gfp_t flags, size_t size) > { > int index = kmalloc_index(size); > > if (index == 0) > return NULL; > > - return kmalloc_caches[index]; > + return memcg_kmem_get_cache(kmalloc_caches[index], flags); > } > > void *kmem_cache_alloc(struct kmem_cache *, gfp_t); > @@ -225,7 +227,13 @@ void *__kmalloc(size_t size, gfp_t flags); > static __always_inline void * > kmalloc_order(size_t size, gfp_t flags, unsigned …
creator: Kirill A. Shutsemov
date: 2012-07-30T12:58:30-00:00

Re: [PATCH 06/10] sl[au]b: Allocate objects from memcg cache
type: item
description: On 07/30/2012 04:58 PM, Kirill A. Shutemov wrote: > On Wed, Jul 25, 2012 at 06:38:17PM +0400, Glauber Costa wrote: >> We are able to match a cache allocation to a particular memcg. If the >> task doesn't change groups during the allocation itself - a rare event, >> this will give us a good picture about who is the first group to touch a >> cache page. >> >> This patch uses the now available infrastructure by calling >> memcg_kmem_get_cache() before all the cache allocations. >> >> Signed-off-by: Glauber Costa <glommer@parallels.com> >> CC: Christoph Lameter <cl@linux.com> >> CC: Pekka Enberg <penberg@cs.helsinki.fi> >> CC: Michal Hocko <mhocko@suse.cz> >> CC: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> >> CC: Johannes Weiner <hannes@cmpxchg.org> >> CC: Suleiman Souhlal <suleiman@google.com> >> --- >> include/linux/slub_def.h | 18 +++++++++++++----- >> mm/memcontrol.c | 2 ++ >> mm/slab.c | 4 ++++ >> mm/slub.c | 1 + >> 4 files changed, 20 insertions(+), 5 deletions(-) >> >> diff --git a/include/linux/slub_def.h b/include/linux/slub_def.h >> index 8bb8ad2..148000a 100644 >> --- a/include/linux/slub_def.h >> +++ b/include/linux/slub_def.h >> @@ -13,6 +13,8 @@ >> #include <linux/kobject.h> >> >> #include <linux/kmemleak.h> >> +#include <linux/memcontrol.h> >> +#include <linux/mm.h> >> >> enum stat_item { >> ALLOC_FASTPATH, /* Allocation from cpu slab */ >> @@ -209,14 +211,14 @@ static __always_inline int kmalloc_index(size_t size) >> * This ought to end up with a global pointer to the right cache >> * in kmalloc_caches. >> */ >> -static __always_inline struct kmem_cache *kmalloc_slab(size_t size) >> +static __always_inline struct kmem_cache *kmalloc_slab(gfp_t flags, size_t size) >> { >> int index = kmalloc_index(size); >> >> if (index == 0) >> return NULL; >> >> - return kmalloc_caches[index]; >> + return memcg_kmem_get_cache(kmalloc_caches[index], flags); >> } >> >> void *kmem_cache_alloc(struct kmem_cache *, gfp_t); >> @@ -225,7 +227,13 @@ void *__kmalloc(size_…
creator: Glauber Costa
date: 2012-07-30T13:11:06-00:00

Re: [PATCH 04/10] memcg: skip memcg kmem allocations in specified code regions
type: item
description: On 07/30/2012 04:50 PM, Kirill A. Shutemov wrote: > On Wed, Jul 25, 2012 at 06:38:15PM +0400, Glauber Costa wrote: >> This patch creates a mechanism that skip memcg allocations during >> certain pieces of our core code. It basically works in the same way >> as preempt_disable()/preempt_enable(): By marking a region under >> which all allocations will be accounted to the root memcg. >> >> We need this to prevent races in early cache creation, when we >> allocate data using caches that are not necessarily created already. > > Why not a GFP_* flag? > The main reason for this is to prevent nested calls of kmem_cache_create(), since they could create (and in my tests, do create) funny circular dependencies with each other. So the cache creation itself would proceed without involving memcg. At first, it is a bit weird to have cache creation itself depending on a allocation flag test.
creator: Glauber Costa
date: 2012-07-30T14:09:23-00:00

Re: [PATCH 00/10] memcg kmem limitation - slab.
type: item
description: On Wed, Jul 25, 2012 at 06:38:11PM +0400, Glauber Costa wrote: > Hi, > > This is the slab part of the kmem limitation mechanism in its last form. I > would like to have comments on it to see if we can agree in its form. I > consider it mature, since it doesn't change much in essence over the last > forms. However, I would still prefer to defer merging it and merge the > stack-only patchset first (even if inside the same merge window). That patchset > contains most of the infrastructure needed here, and merging them separately > would not only reduce the complexity for reviewers, but allow us a chance to > have independent testing on them both. I would also likely benefit from some > extra testing, to make sure the recent changes didn't introduce anything bad. What is the status of the stack-only limitation patchset BTW? Does anybody oppose to its merging? Thanks.
creator: Frederic Weisbecker
date: 2012-07-31T16:30:31-00:00

Re: [PATCH 00/10] memcg kmem limitation - slab.
type: item
description: On 07/31/2012 08:30 PM, Frederic Weisbecker wrote: > On Wed, Jul 25, 2012 at 06:38:11PM +0400, Glauber Costa wrote: >> Hi, >> >> This is the slab part of the kmem limitation mechanism in its last form. I >> would like to have comments on it to see if we can agree in its form. I >> consider it mature, since it doesn't change much in essence over the last >> forms. However, I would still prefer to defer merging it and merge the >> stack-only patchset first (even if inside the same merge window). That patchset >> contains most of the infrastructure needed here, and merging them separately >> would not only reduce the complexity for reviewers, but allow us a chance to >> have independent testing on them both. I would also likely benefit from some >> extra testing, to make sure the recent changes didn't introduce anything bad. > > What is the status of the stack-only limitation patchset BTW? Does anybody oppose > to its merging? > > Thanks. > Andrew said he would like to see the slab patches in a relatively mature state first. I do believe they are in such a state. There are bugs, that I am working on - but I don't see anything that would change them significantly at this point. If Andrew is happy with what he saw in this thread, I could post those again.
creator: Glauber Costa
date: 2012-07-31T16:39:30-00:00