OpenVZ Forum - RDF feed
type: channel
items: [PATCH v3 00/28] kmem limitation for memcg
items: [PATCH v3 01/28] slab: move FULL state transition to an initcall
items: [PATCH v3 02/28] memcg: Always free struct memcg through schedule_work()
items: [PATCH v3 03/28] slab: rename gfpflags to allocflags
items: [PATCH v3 06/28] slab: use obj_size field of struct kmem_cache when not debugging
items: [PATCH v3 08/28] res_counter: don't force return value checking in res_counter_charge_nofail
items: [PATCH v3 09/28] kmem slab accounting basic infrastructure
items: [PATCH v3 10/28] slab/slub: struct memcg_params
items: [PATCH v3 11/28] slub: consider a memcg parameter in kmem_create_cache
items: [PATCH v3 12/28] slab: pass memcg parameter to kmem_cache_create
items: [PATCH v3 13/28] slub: create duplicate cache
items: [PATCH v3 14/28] slab: create duplicate cache
items: [PATCH v3 15/28] slub: always get the cache from its page in kfree
items: [PATCH v3 16/28] memcg: kmem controller charge/uncharge infrastructure
items: [PATCH v3 17/28] skip memcg kmem allocations in specified code regions
items: [PATCH v3 18/28] slub: charge allocation to a memcg
items: [PATCH v3 19/28] slab: per-memcg accounting of slab caches
items: [PATCH v3 20/28] memcg: disable kmem code when not in use.
items: [PATCH v3 21/28] memcg: destroy memcg caches
items: [PATCH v3 22/28] memcg/slub: shrink dead caches
items: [PATCH v3 23/28] slab: Track all the memcg children of a kmem_cache.
items: [PATCH v3 24/28] memcg: Per-memcg memory.kmem.slabinfo file.
items: [PATCH v3 25/28] slub: create slabinfo file for memcg
items: [PATCH v3 26/28] slub: track all children of a kmem cache
items: [PATCH v3 27/28] memcg: propagate kmem limiting information to children
items: [PATCH v3 28/28] Documentation: add documentation for slab tracker for memcg
items: Re: [PATCH v3 00/28] kmem limitation for memcg
items: Re: [PATCH v3 12/28] slab: pass memcg parameter to kmem_cache_create
items: Re: [PATCH v3 13/28] slub: create duplicate cache
items: Re: [PATCH v3 15/28] slub: always get the cache from its page in kfree
items: Re: [PATCH v3 16/28] memcg: kmem controller charge/uncharge infrastructure
items: Re: [PATCH v3 18/28] slub: charge allocation to a memcg
items: Re: [PATCH v3 19/28] slab: per-memcg accounting of slab caches
items: Re: Re: [PATCH v3 13/28] slub: create duplicate cache

[PATCH v3 00/28] kmem limitation for memcg
type: item
description: Hello All, This is my new take for the memcg kmem accounting. This should merge all of the previous comments from you, plus fix a bunch of bugs. At this point, I consider the series pretty mature. Since last submission 2 weeks ago, I focused on broadening the testing coverage. Some bugs were fixed, but that of course doesn't mean no bugs exist. I believe some of the early patches here are already in some trees around. I don't know who should pick this, so if everyone agrees with what's in here, please just ack them and tell me which tree I should aim for (-mm? Hocko's?) and I'll rebase it. I should point out again that most, if not all, of the code in the caches are wrapped in static_key areas, meaning they will be completely patched out until the first limit is set. Enabling and disabling of static_keys incorporate the last fixes for sock memcg, and should be pretty robust. I also put a lot of effort, as you will all see, in the proper separation of the patches, so the review process is made as easy as the complexity of the work allows to. [ v3 ] * fixed lockdep bugs in slab (ordering of get_online_cpus() vs slab_mutex) * improved style in slab and slub with less #ifdefs in-code * tested and fixed hierarchical accounting (memcg: propagate kmem limiting...) * some more small bug fixes * No longer using res_counter_charge_nofail for GFP_NOFAIL submissions. Those go to the root memcg directly. * reordered tests in mem_cgroup_get_kmem_cache so we exit even earlier for tasks in root memcg * no more memcg state for slub initialization * do_tune_cpucache will always (only after FULL) propagate to children when they exist. * slab itself will destroy the kmem_cache string for chained caches, so we don't need to bother with consistency between them. * other minor issues [ v2 ] * memcgs can be properly removed. * We are not charging based on current->mm->owner instead of current * kmem_large allocations for slub got some fixes, specially for the free case * A cache that is re…
creator: Glauber Costa
date: 2012-05-25T13:03:20-00:00

[PATCH v3 01/28] slab: move FULL state transition to an initcall
type: item
description: During kmem_cache_init_late(), we transition to the LATE state, and after some more work, to the FULL state, its last state This is quite different from slub, that will only transition to its last state (SYSFS), in a (late)initcall, after a lot more of the kernel is ready. This means that in slab, we have no way to taking actions dependent on the initialization of other pieces of the kernel that are supposed to start way after kmem_init_late(), such as cgroups initialization. To achieve more consistency in this behavior, that patch only transitions to the LATE state in kmem_init_late. In my analysis, setup_cpu_cache() should be happy to test for >= LATE, instead of == FULL. It also has passed some tests I've made. We then only mark FULL state after the reap timers are in place, meaning that no further setup is expected. Signed-off-by: Glauber Costa <glommer@parallels.com> Acked-by: Christoph Lameter <cl@linux.com> CC: Pekka Enberg <penberg@cs.helsinki.fi> CC: David Rientjes <rientjes@google.com> --- mm/slab.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/mm/slab.c b/mm/slab.c index e901a36..8658d72 100644 --- a/mm/slab.c +++ b/mm/slab.c @@ -1695,9 +1695,6 @@ void __init kmem_cache_init_late(void) BUG(); mutex_unlock(&cache_chain_mutex); - /* Done! */ - g_cpucache_up = FULL; - /* * Register a cpu startup notifier callback that initializes * cpu_cache_get for all new cpus @@ -1727,6 +1724,9 @@ static int __init cpucache_init(void) */ for_each_online_cpu(cpu) start_cpu_timer(cpu); + + /* Done! */ + g_cpucache_up = FULL; return 0; } __initcall(cpucache_init); @@ -2194,7 +2194,7 @@ static size_t calculate_slab_order(struct kmem_cache *cachep, static int __init_refok setup_cpu_cache(struct kmem_cache *cachep, gfp_t gfp) { - if (g_cpucache_up == FULL) + if (g_cpucache_up >= LATE) return enable_cpucache(cachep, gfp); if (g_cpucache_up == NONE) { -- 1.7.7.6
creator: Glauber Costa
date: 2012-05-25T13:03:21-00:00

[PATCH v3 02/28] memcg: Always free struct memcg through schedule_work()
type: item
description: Right now we free struct memcg with kfree right after a rcu grace period, but defer it if we need to use vfree() to get rid of that memory area. We do that by need, because we need vfree to be called in a process context. This patch unifies this behavior, by ensuring that even kfree will happen in a separate thread. The goal is to have a stable place to call the upcoming jump label destruction function outside the realm of the complicated and quite far-reaching cgroup lock (that can't be held when calling neither the cpu_hotplug.lock nor the jump_label_mutex) Signed-off-by: Glauber Costa <glommer@parallels.com> CC: Tejun Heo <tj@kernel.org> CC: Li Zefan <lizefan@huawei.com> CC: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> CC: Johannes Weiner <hannes@cmpxchg.org> CC: Michal Hocko <mhocko@suse.cz> --- mm/memcontrol.c | 24 +++++++++++++----------- 1 files changed, 13 insertions(+), 11 deletions(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 932a734..0b4b4c8 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -245,8 +245,8 @@ struct mem_cgroup { */ struct rcu_head rcu_freeing; /* - * But when using vfree(), that cannot be done at - * interrupt time, so we must then queue the work. + * We also need some space for a worker in deferred freeing. + * By the time we call it, rcu_freeing is not longer in use. */ struct work_struct work_freeing; }; @@ -4826,23 +4826,28 @@ out_free: } /* - * Helpers for freeing a vzalloc()ed mem_cgroup by RCU, + * Helpers for freeing a kmalloc()ed/vzalloc()ed mem_cgroup by RCU, * but in process context. The work_freeing structure is overlaid * on the rcu_freeing structure, which itself is overlaid on memsw. */ -static void vfree_work(struct work_struct *work) +static void free_work(struct work_struct *work) { struct mem_cgroup *memcg; + int size = sizeof(struct mem_cgroup); memcg = container_of(work, struct mem_cgroup, work_freeing); - vfree(memcg); + if (size < PAGE_SIZE) + kfree(memcg); + else + vfree(memcg); } -static void vf…
creator: Glauber Costa
date: 2012-05-25T13:03:22-00:00

[PATCH v3 03/28] slab: rename gfpflags to allocflags
type: item
description: A consistent name with slub saves us an acessor function. In both caches, this field represents the same thing. We would like to use it from the mem_cgroup code. Signed-off-by: Glauber Costa <glommer@parallels.com> Acked-by: Christoph Lameter <cl@linux.com> CC: Pekka Enberg <penberg@cs.helsinki.fi> --- include/linux/slab_def.h | 2 +- mm/slab.c | 10 +++++----- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/include/linux/slab_def.h b/include/linux/slab_def.h index fbd1117..d41effe 100644 --- a/include/linux/slab_def.h +++ b/include/linux/slab_def.h @@ -39,7 +39,7 @@ struct kmem_cache { unsigned int gfporder; /* force GFP flags, e.g. GFP_DMA */ - gfp_t gfpflags; + gfp_t allocflags; size_t colour; /* cache colouring range */ unsigned int colour_off; /* colour offset */ diff --git a/mm/slab.c b/mm/slab.c index 8658d72..1057a32 100644 --- a/mm/slab.c +++ b/mm/slab.c @@ -1798,7 +1798,7 @@ static void *kmem_getpages(struct kmem_cache *cachep, gfp_t flags, int nodeid) flags |= __GFP_COMP; #endif - flags |= cachep->gfpflags; + flags |= cachep->allocflags; if (cachep->flags & SLAB_RECLAIM_ACCOUNT) flags |= __GFP_RECLAIMABLE; @@ -2508,9 +2508,9 @@ kmem_cache_create (const char *name, size_t size, size_t align, cachep->colour = left_over / cachep->colour_off; cachep->slab_size = slab_size; cachep->flags = flags; - cachep->gfpflags = 0; + cachep->allocflags = 0; if (CONFIG_ZONE_DMA_FLAG && (flags & SLAB_CACHE_DMA)) - cachep->gfpflags |= GFP_DMA; + cachep->allocflags |= GFP_DMA; cachep->buffer_size = size; cachep->reciprocal_buffer_size = reciprocal_value(size); @@ -2857,9 +2857,9 @@ static void kmem_flagcheck(struct kmem_cache *cachep, gfp_t flags) { if (CONFIG_ZONE_DMA_FLAG) { if (flags & GFP_DMA) - BUG_ON(!(cachep->gfpflags & GFP_DMA)); + BUG_ON(!(cachep->allocflags & GFP_DMA)); else - BUG_ON(cachep->gfpflags & GFP_DMA); + BUG_ON(cachep->allocflags & GFP_DMA); } } -- 1.7.7.6
creator: Glauber Costa
date: 2012-05-25T13:03:23-00:00

[PATCH v3 06/28] slab: use obj_size field of struct kmem_cache when not debugging
type: item
description: The kmem controller needs to keep track of the object size of a cache so it can later on create a per-memcg duplicate. Logic to keep track of that already exists, but it is only enable while debugging. This patch makes it also available when the kmem controller code is compiled in. Signed-off-by: Glauber Costa <glommer@parallels.com> CC: Christoph Lameter <cl@linux.com> CC: Pekka Enberg <penberg@cs.helsinki.fi> --- include/linux/slab_def.h | 4 +++- mm/slab.c | 37 ++++++++++++++++++++++++++----------- 2 files changed, 29 insertions(+), 12 deletions(-) diff --git a/include/linux/slab_def.h b/include/linux/slab_def.h index d41effe..cba3139 100644 --- a/include/linux/slab_def.h +++ b/include/linux/slab_def.h @@ -78,8 +78,10 @@ struct kmem_cache { * variables contain the offset to the user object and its size. */ int obj_offset; - int obj_size; #endif /* CONFIG_DEBUG_SLAB */ +#if defined(CONFIG_DEBUG_SLAB) || defined(CONFIG_CGROUP_MEM_RES_CTLR_KMEM) + int obj_size; +#endif /* 6) per-cpu/per-node data, touched during every alloc/free */ /* diff --git a/mm/slab.c b/mm/slab.c index 1057a32..41345f6 100644 --- a/mm/slab.c +++ b/mm/slab.c @@ -413,8 +413,28 @@ static void kmem_list3_init(struct kmem_list3 *parent) #define STATS_INC_FREEMISS(x) do { } while (0) #endif -#if DEBUG +#if defined(CONFIG_DEBUG_SLAB) || defined(CONFIG_CGROUP_MEM_RES_CTLR_KMEM) +static int obj_size(struct kmem_cache *cachep) +{ + return cachep->obj_size; +} +static void set_obj_size(struct kmem_cache *cachep, int size) +{ + cachep->obj_size = size; +} + +#else +static int obj_size(struct kmem_cache *cachep) +{ + return cachep->buffer_size; +} + +static void set_obj_size(struct kmem_cache *cachep, int size) +{ +} +#endif +#if DEBUG /* * memory layout of objects: * 0 : objp @@ -433,11 +453,6 @@ static int obj_offset(struct kmem_cache *cachep) return cachep->obj_offset; } -static int obj_size(struct kmem_cache *cachep) -{ - return cachep->obj_size; -} - static unsigned long long *dbg_redzone1(struct kmem_…
creator: Glauber Costa
date: 2012-05-25T13:03:26-00:00

[PATCH v3 08/28] res_counter: don't force return value checking in res_counter_charge_nofail
type: item
description: Since we will succeed with the allocation no matter what, there isn't the need to use __must_check with it. It can very well be optional. Signed-off-by: Glauber Costa <glommer@parallels.com> Acked-by: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> CC: Johannes Weiner <hannes@cmpxchg.org> CC: Michal Hocko <mhocko@suse.cz> --- include/linux/res_counter.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/linux/res_counter.h b/include/linux/res_counter.h index da81af0..f7621cf 100644 --- a/include/linux/res_counter.h +++ b/include/linux/res_counter.h @@ -119,7 +119,7 @@ int __must_check res_counter_charge_locked(struct res_counter *counter, unsigned long val); int __must_check res_counter_charge(struct res_counter *counter, unsigned long val, struct res_counter **limit_fail_at); -int __must_check res_counter_charge_nofail(struct res_counter *counter, +int res_counter_charge_nofail(struct res_counter *counter, unsigned long val, struct res_counter **limit_fail_at); /* -- 1.7.7.6
creator: Glauber Costa
date: 2012-05-25T13:03:28-00:00

[PATCH v3 09/28] kmem slab accounting basic infrastructure
type: item
description: This patch adds the basic infrastructure for the accounting of the slab caches. To control that, the following files are created: * memory.kmem.usage_in_bytes * memory.kmem.limit_in_bytes * memory.kmem.failcnt * memory.kmem.max_usage_in_bytes They have the same meaning of their user memory counterparts. They reflect the state of the "kmem" res_counter. The code is not enabled until a limit is set. This can be tested by the flag "kmem_accounted". This means that after the patch is applied, no behavioral changes exists for whoever is still using memcg to control their memory usage. We always account to both user and kernel resource_counters. This effectively means that an independent kernel limit is in place when the limit is set to a lower value than the user memory. A equal or higher value means that the user limit will always hit first, meaning that kmem is effectively unlimited. People who want to track kernel memory but not limit it, can set this limit to a very high number (like RESOURCE_MAX - 1page - that no one will ever hit, or equal to the user memory) Signed-off-by: Glauber Costa <glommer@parallels.com> CC: Michal Hocko <mhocko@suse.cz> CC: Johannes Weiner <hannes@cmpxchg.org> Reviewed-by: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> --- mm/memcontrol.c | 78 ++++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 files changed, 77 insertions(+), 1 deletions(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 789ca5a..b6bac5f 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -252,6 +252,10 @@ struct mem_cgroup { }; /* + * the counter to account for kernel memory usage. + */ + struct res_counter kmem; + /* * Per cgroup active and inactive list, similar to the * per zone LRU lists. */ @@ -266,6 +270,7 @@ struct mem_cgroup { * Should the accounting and control be hierarchical, per subtree? */ bool use_hierarchy; + bool kmem_accounted; bool oom_lock; atomic_t under_oom; @@ -378,6 +383,7 @@ enum res_type { _MEM, _MEMSWAP, _OOM_TYPE, + _KMEM, }; #d…
creator: Glauber Costa
date: 2012-05-25T13:03:29-00:00

[PATCH v3 10/28] 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 | 14 ++++++++++++++ include/linux/slab_def.h | 4 ++++ include/linux/slub_def.h | 3 +++ 3 files changed, 21 insertions(+), 0 deletions(-) diff --git a/include/linux/slab.h b/include/linux/slab.h index a595dce..dbf36b5 100644 --- a/include/linux/slab.h +++ b/include/linux/slab.h @@ -153,6 +153,20 @@ unsigned int kmem_cache_size(struct kmem_cache *); #define ARCH_SLAB_MINALIGN __alignof__(unsigned long long) #endif +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM +struct mem_cgroup_cache_params { + struct mem_cgroup *memcg; + int id; + atomic_t refcnt; + +#ifdef CONFIG_SLAB + /* Original cache parameters, used when creating a memcg cache */ + size_t orig_align; + +#endif +}; +#endif + /* * Common kmalloc functions provided by all allocators */ diff --git a/include/linux/slab_def.h b/include/linux/slab_def.h index cba3139..06e4a3e 100644 --- a/include/linux/slab_def.h +++ b/include/linux/slab_def.h @@ -83,6 +83,10 @@ struct kmem_cache { int obj_size; #endif +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_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 c2f8c8b..5f5e942 100644 --- a/include/linux/slub_def.h +++ b/include/linux/slub_def.h @@ -102,6 +102,9 @@ struct kmem_cache { #ifdef CONFIG_SYSFS struct kobject kobj; /* For sysfs */ #endif +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM + struct mem_cgroup_cache_params memcg_params; +#endif #ifdef CONFIG…
creator: Glauber Costa
date: 2012-05-25T13:03:30-00:00

[PATCH v3 11/28] slub: consider a memcg parameter in kmem_create_cache
type: item
description: Allow a memcg parameter to be passed during cache creation. The slub allocator 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 | 6 ++++ mm/memcontrol.c | 27 ++++++++++++++++++++ mm/slub.c | 58 ++++++++++++++++++++++++++++++++++++++++--- 4 files changed, 101 insertions(+), 4 deletions(-) diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h index f94efd2..99e14b9 100644 --- a/include/linux/memcontrol.h +++ b/include/linux/memc…
creator: Glauber Costa
date: 2012-05-25T13:03:31-00:00

[PATCH v3 12/28] slab: pass memcg parameter to kmem_cache_create
type: item
description: Allow a memcg parameter to be passed during cache creation. Default function is created as a wrapper, passing NULL to the memcg version. We only merge caches that belong to the same memcg. This code was mostly written by Suleiman Souhlal and only adapted to my patchset, plus a couple of simplifications [ v3: get_online_cpus need to be outside slab mutex. ] [ also, register all caches created before FULL state ] 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_def.h | 7 ++++ mm/slab.c | 79 ++++++++++++++++++++++++++++++++++++---------- 2 files changed, 69 insertions(+), 17 deletions(-) diff --git a/include/linux/slab_def.h b/include/linux/slab_def.h index 06e4a3e..7c0cdd6 100644 --- a/include/linux/slab_def.h +++ b/include/linux/slab_def.h @@ -102,6 +102,13 @@ struct kmem_cache { */ }; +static inline void store_orig_align(struct kmem_cache *cachep, int orig_align) +{ +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM + cachep->memcg_params.orig_align = orig_align; +#endif +} + /* Size description struct for general caches. */ struct cache_sizes { size_t cs_size; diff --git a/mm/slab.c b/mm/slab.c index 41345f6..8bff32a1 100644 --- a/mm/slab.c +++ b/mm/slab.c @@ -1729,6 +1729,31 @@ void __init kmem_cache_init_late(void) */ } +static int __init memcg_slab_register_all(void) +{ +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM + struct kmem_cache *cachep; + struct cache_sizes *sizes; + + sizes = malloc_sizes; + + while (sizes->cs_size != ULONG_MAX) { + if (sizes->cs_cachep) + mem_cgroup_register_cache(NULL, sizes->cs_cachep); + if (sizes->cs_dmacachep) + mem_cgroup_register_cache(NULL, sizes->cs_dmacachep); + sizes++; + } + + mutex_lock(&cache_chain_mutex); + list_for_each_entry(cachep, &cache_chain, next)…
creator: Glauber Costa
date: 2012-05-25T13:03:32-00:00

[PATCH v3 13/28] slub: create duplicate cache
type: item
description: This patch provides kmem_cache_dup(), that duplicates a cache for a memcg, preserving its creation properties. Object size, alignment and flags are all respected. When a duplicate cache is created, the parent cache cannot be destructed during the child lifetime. To assure this, its reference count is increased if the cache creation succeeds. 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 | 2 ++ include/linux/slab.h | 2 ++ mm/memcontrol.c | 17 +++++++++++++++++ mm/slub.c | 32 ++++++++++++++++++++++++++++++++ 4 files changed, 53 insertions(+), 0 deletions(-) diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h index 99e14b9..f93021a 100644 --- a/include/linux/memcontrol.h +++ b/include/linux/memcontrol.h @@ -445,6 +445,8 @@ int memcg_css_id(struct mem_cgroup *memcg); void mem_cgroup_register_cache(struct mem_cgroup *memcg, struct kmem_cache *s); void mem_cgroup_release_cache(struct kmem_cache *cachep); +extern char *mem_cgroup_cache_name(struct mem_cgroup *memcg, + struct kmem_cache *cachep); #else static inline void mem_cgroup_register_cache(struct mem_cgroup *memcg, struct kmem_cache *s) diff --git a/include/linux/slab.h b/include/linux/slab.h index 1386650..e73ef71 100644 --- a/include/linux/slab.h +++ b/include/linux/slab.h @@ -322,6 +322,8 @@ extern void *__kmalloc_track_caller(size_t, gfp_t, unsigned long); #ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM #define MAX_KMEM_CACHE_TYPES 400 +extern struct kmem_cache *kmem_cache_dup(struct mem_cgroup *memcg, + struct kmem_cache *cachep); #else #define MAX_KMEM_CACHE_TYPES 0 #endif /* CONFIG_CGROUP_MEM_RES_CTLR_KMEM */ diff --git a/mm/memcontrol.c b/mm/memcontrol.c index dacd1fb..4689034 100644 --- a/mm/memcontrol.c +++ b/mm/me…
creator: Glauber Costa
date: 2012-05-25T13:03:33-00:00

[PATCH v3 14/28] slab: create duplicate cache
type: item
description: This patch provides kmem_cache_dup(), that duplicates a cache for a memcg, preserving its creation properties. Object size, alignment and flags are all respected. An exception is the SLAB_PANIC flag, since cache creation inside a memcg should not be fatal. This code is mostly written by Suleiman Souhlal, with some adaptations and simplifications by me. [ v3: add get_online cpus before the slab mutex ] 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> --- mm/slab.c | 44 ++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 44 insertions(+), 0 deletions(-) diff --git a/mm/slab.c b/mm/slab.c index 8bff32a1..e2227de 100644 --- a/mm/slab.c +++ b/mm/slab.c @@ -301,6 +301,8 @@ static void free_block(struct kmem_cache *cachep, void **objpp, int len, int node); static int enable_cpucache(struct kmem_cache *cachep, gfp_t gfp); static void cache_reap(struct work_struct *unused); +static int do_tune_cpucache(struct kmem_cache *cachep, int limit, + int batchcount, int shared, gfp_t gfp); /* * This function must be completely optimized away if a constant is passed to @@ -2616,6 +2618,42 @@ kmem_cache_create(const char *name, size_t size, size_t align, } EXPORT_SYMBOL(kmem_cache_create); +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM +struct kmem_cache *kmem_cache_dup(struct mem_cgroup *memcg, + struct kmem_cache *cachep) +{ + struct kmem_cache *new; + unsigned long flags; + char *name; + + name = mem_cgroup_cache_name(memcg, cachep); + if (!name) + return NULL; + + flags = cachep->flags & ~(SLAB_PANIC|CFLGS_OFF_SLAB); + + get_online_cpus(); + mutex_lock(&cache_chain_mutex); + new = __kmem_cache_create(memcg, name, obj_size(cachep), + cachep->memcg_params.orig_align, flags, cachep->ctor); + + if (new == NULL) { + kfree…
creator: Glauber Costa
date: 2012-05-25T13:03:34-00:00

[PATCH v3 15/28] slub: always get the cache from its page in kfree
type: item
description: struct page already have this information. If we start chaining caches, this information will always be more trustworthy than whatever is passed into the function A parent pointer is added to the slub structure, so we can make sure the freeing comes from either the right slab, or from its rightful parent. [ v3: added parent testing with VM_BUG_ON ] Signed-off-by: Glauber Costa <glommer@parallels.com> CC: Christoph Lameter <cl@linux.com> CC: Pekka Enberg <penberg@cs.helsinki.fi> --- include/linux/slab.h | 3 +++ include/linux/slub_def.h | 18 ++++++++++++++++++ mm/slub.c | 7 ++++++- 3 files changed, 27 insertions(+), 1 deletions(-) diff --git a/include/linux/slab.h b/include/linux/slab.h index e73ef71..724c143 100644 --- a/include/linux/slab.h +++ b/include/linux/slab.h @@ -164,6 +164,9 @@ struct mem_cgroup_cache_params { size_t orig_align; #endif +#ifdef CONFIG_DEBUG_VM + struct kmem_cache *parent; +#endif }; #endif diff --git a/include/linux/slub_def.h b/include/linux/slub_def.h index 5f5e942..f822ca2 100644 --- a/include/linux/slub_def.h +++ b/include/linux/slub_def.h @@ -115,6 +115,24 @@ struct kmem_cache { struct kmem_cache_node *node[MAX_NUMNODES]; }; +static inline void slab_set_parent(struct kmem_cache *s, + struct kmem_cache *parent) +{ +#if defined(CONFIG_CGROUP_MEM_RES_CTLR_KMEM) && defined(CONFIG_DEBUG_VM) + s->memcg_params.parent = parent; +#endif +} + +static inline bool slab_is_parent(struct kmem_cache *s, + struct kmem_cache *candidate) +{ +#if defined(CONFIG_CGROUP_MEM_RES_CTLR_KMEM) && defined(CONFIG_DEBUG_VM) + return candidate == s->memcg_params.parent; +#else + return false; +#endif +} + /* * Kmalloc subsystem. */ diff --git a/mm/slub.c b/mm/slub.c index 0eb9e72..640872f 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -2598,10 +2598,14 @@ redo: void kmem_cache_free(struct kmem_cache *s, void *x) { struct page *page; + bool slab_match; page = virt_to_head_page(x); - slab_free(s, page, x, _RET_IP_); + slab_match = (page->slab == s) | slab_is_parent(page->s…
creator: Glauber Costa
date: 2012-05-25T13:03:35-00:00

[PATCH v3 16/28] memcg: kmem controller charge/uncharge infrastructure
type: item
description: With all the dependencies already in place, this patch introduces the charge/uncharge functions for the slab cache accounting in memcg. Before we can charge a cache, we need to select the right cache. This is done by using the function __mem_cgroup_get_kmem_cache(). If we should use the root kmem cache, this function tries to detect that and return as early as possible. The charge and uncharge functions comes in two flavours: * __mem_cgroup_(un)charge_slab(), that assumes the allocation is a slab page, and * __mem_cgroup_(un)charge_kmem(), that does not. This later exists because the slub allocator draws the larger kmalloc allocations from the page allocator. In memcontrol.h those functions are wrapped in inline acessors. The idea is to later on, patch those with jump labels, so we don't incur any overhead when no mem cgroups are being used. Because the slub allocator tends to inline the allocations whenever it can, those functions need to be exported so modules can make use of it properly. This code is inspired by the code written by Suleiman Souhlal, but heavily changed. 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/memcontrol.h | 80 +++++++++ init/Kconfig | 2 +- mm/memcontrol.c | 386 +++++++++++++++++++++++++++++++++++++++++++- 3 files changed, 466 insertions(+), 2 deletions(-) diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h index f93021a..fbc5ba1 100644 --- a/include/linux/memcontrol.h +++ b/include/linux/memcontrol.h @@ -21,6 +21,7 @@ #define _LINUX_MEMCONTROL_H #include <linux/cgroup.h> #include <linux/vm_event_item.h> +#include <linux/hardirq.h> struct mem_cgroup; struct page_cgroup; @@ -447,6 +448,19 @@ void mem_cgroup_register_cache(struct mem_cgroup *me…
creator: Glauber Costa
date: 2012-05-25T13:03:36-00:00

[PATCH v3 17/28] 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 | 25 +++++++++++++++++++++++++ 2 files changed, 26 insertions(+), 0 deletions(-) diff --git a/include/linux/sched.h b/include/linux/sched.h index 81a173c..0761dda 100644 --- a/include/linux/sched.h +++ b/include/linux/sched.h @@ -1613,6 +1613,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 44589fb..f3a3812 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -479,6 +479,21 @@ struct cg_proto *tcp_proto_cgroup(struct mem_cgroup *memcg) EXPORT_SYMBOL(tcp_proto_cgroup); #endif /* CONFIG_INET */ +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--; +} char *mem_cgroup_cache_name(struct mem_cgroup *memcg, struct kmem_cache *cachep) { char *name; @@ -540,7 +555,9 @@ static struct kmem_cache *memcg_create_kmem_cache(struct mem_cgroup *memcg, if (new_cachep) goto out; + memcg_stop_kmem_account(); new_cachep …
creator: Glauber Costa
date: 2012-05-25T13:03:37-00:00

[PATCH v3 18/28] slub: charge allocation to a memcg
type: item
description: This patch charges allocation of a slab object to a particular memcg. The cache is selected with mem_cgroup_get_kmem_cache(), which is the biggest overhead we pay here, because it happens at all allocations. However, other than forcing a function call, this function is not very expensive, and try to return as soon as we realize we are not a memcg cache. The charge/uncharge functions are heavier, but are only called for new page allocations. The kmalloc_no_account variant is patched so the base function is used and we don't even try to do cache selection. 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 | 39 ++++++++++++++++++--- mm/slub.c | 87 +++++++++++++++++++++++++++++++++++++++++----- 2 files changed, 112 insertions(+), 14 deletions(-) diff --git a/include/linux/slub_def.h b/include/linux/slub_def.h index f822ca2..ba9c68b 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 */ @@ -228,27 +230,54 @@ 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) { + struct kmem_cache *s; int index = kmalloc_index(size); if (index == 0) return NULL; - return kmalloc_caches[index]; + s = kmalloc_caches[index]; + + rcu_read_lock(); + s = mem_cgroup_get_kmem_cache(s, flags); + rcu_read_unlock(); + + return s; } void *kmem_cache_alloc(struct kmem_cache *, gfp_t);…
creator: Glauber Costa
date: 2012-05-25T13:03:38-00:00

[PATCH v3 19/28] slab: per-memcg accounting of slab caches
type: item
description: This patch charges allocation of a slab object to a particular memcg. The cache is selected with mem_cgroup_get_kmem_cache(), which is the biggest overhead we pay here, because it happens at all allocations. However, other than forcing a function call, this function is not very expensive, and try to return as soon as we realize we are not a memcg cache. The charge/uncharge functions are heavier, but are only called for new page allocations. Code is heavily inspired by Suleiman's, with adaptations to the patchset and minor simplifications by me. 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_def.h | 62 +++++++++++++++++++++++++++++ mm/slab.c | 98 +++++++++++++++++++++++++++++++++++++++++---- 2 files changed, 151 insertions(+), 9 deletions(-) diff --git a/include/linux/slab_def.h b/include/linux/slab_def.h index 7c0cdd6..ea9054a 100644 --- a/include/linux/slab_def.h +++ b/include/linux/slab_def.h @@ -225,4 +225,66 @@ found: #endif /* CONFIG_NUMA */ +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM + +void kmem_cache_drop_ref(struct kmem_cache *cachep); + +static inline void +kmem_cache_get_ref(struct kmem_cache *cachep) +{ + if (cachep->memcg_params.id == -1 && + unlikely(!atomic_add_unless(&cachep->memcg_params.refcnt, 1, 0))) + BUG(); +} + +static inline void +mem_cgroup_put_kmem_cache(struct kmem_cache *cachep) +{ + rcu_read_unlock(); +} + +static inline void +mem_cgroup_kmem_cache_prepare_sleep(struct kmem_cache *cachep) +{ + /* + * Make sure the cache doesn't get freed while we have interrupts + * enabled. + */ + kmem_cache_get_ref(cachep); +} + +static inline void +mem_cgroup_kmem_cache_finish_sleep(struct kmem_cache *cachep) +{ + kmem_cache_drop_ref(cachep); +} + +#else /* CONFIG_CGRO…
creator: Glauber Costa
date: 2012-05-25T13:03:39-00:00

[PATCH v3 20/28] memcg: disable kmem code when not in use.
type: item
description: We can use jump labels to patch the code in or out when not used. Because the assignment: memcg->kmem_accounted = true is done after the jump labels increment, we guarantee that the root memcg will always be selected until all call sites are patched (see mem_cgroup_kmem_enabled). This guarantees that no mischarges are applied. Jump label decrement happens when the last reference count from the memcg dies. This will only happen when the caches are all dead. 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 | 4 +++- mm/memcontrol.c | 22 +++++++++++++++++++++- 2 files changed, 24 insertions(+), 2 deletions(-) diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h index fbc5ba1..bad8ebd 100644 --- a/include/linux/memcontrol.h +++ b/include/linux/memcontrol.h @@ -22,6 +22,7 @@ #include <linux/cgroup.h> #include <linux/vm_event_item.h> #include <linux/hardirq.h> +#include <linux/jump_label.h> struct mem_cgroup; struct page_cgroup; @@ -460,7 +461,8 @@ void __mem_cgroup_free_kmem_page(struct page *page); struct kmem_cache * __mem_cgroup_get_kmem_cache(struct kmem_cache *cachep, gfp_t gfp); -#define mem_cgroup_kmem_on 1 +extern struct static_key mem_cgroup_kmem_enabled_key; +#define mem_cgroup_kmem_on static_key_false(&mem_cgroup_kmem_enabled_key) #else static inline void mem_cgroup_register_cache(struct mem_cgroup *memcg, struct kmem_cache *s) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index f3a3812..f2f1525 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -422,6 +422,10 @@ static void mem_cgroup_put(struct mem_cgroup *memcg); #include <net/sock.h> #include <net/ip.h> +struct static_key mem_cgroup_kmem_enabled_key; +/* so modules can inline the checks */ +EXPORT_SYMBOL(m…
creator: Glauber Costa
date: 2012-05-25T13:03:40-00:00

[PATCH v3 21/28] 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 | 2 + include/linux/slab.h | 1 + mm/memcontrol.c | 91 +++++++++++++++++++++++++++++++++++++++++++- mm/slab.c | 5 +- mm/slub.c | 7 ++- 5 files changed, 101 insertions(+), 5 deletions(-) diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h index bad8ebd..df049e1 100644 --- a/include/linux/memcontrol.h +++ b/include/linux/memcontrol.h @@ -463,6 +463,8 @@ __mem_cgroup_get_kmem_cache(struct kmem_cache *cachep, gfp_t gfp); extern struct static_key mem_cgroup_kmem_enabled_key; #define mem_cgroup_kmem_on static_key_false(&mem_cgroup_kmem_enabled_key) + +void mem_cgroup_destroy_cache(struct kmem_cache *cachep); #else static inline void mem_cgroup_register_cache(struct mem_cgroup *memcg, struct kmem_cache *s) diff --git a/include/linux/slab.h b/include/linux/slab.h index 724c143..c81a5d3 100644 --- a/include/linux/slab.h +++ b/include/linux/slab.h @@ -167,6 +167,7 @@ struct mem_cgroup_cache_params { #ifdef CONFIG_DEBUG_VM struct kmem_cache *parent; #endif + struct list_head destroyed_list; /* Used when deleting memcg cache */ }; #endif diff --git a/mm/memcontrol.c b/mm/memcontrol.c index f2f1525..e2ba527 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -476,6 +476,11 @@ static void disarm_static_keys(struct m…
creator: Glauber Costa
date: 2012-05-25T13:03:41-00:00

[PATCH v3 22/28] memcg/slub: 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. 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 | 4 +++ include/linux/slub_def.h | 8 +++++++ mm/memcontrol.c | 49 +++++++++++++++++++++++++++++++++++++++++++-- mm/slub.c | 1 + 4 files changed, 59 insertions(+), 3 deletions(-) diff --git a/include/linux/slab.h b/include/linux/slab.h index c81a5d3..25f073e 100644 --- a/include/linux/slab.h +++ b/include/linux/slab.h @@ -154,10 +154,14 @@ unsigned int kmem_cache_size(struct kmem_cache *); #endif #ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM +#include <linux/workqueue.h> + struct mem_cgroup_cache_params { struct mem_cgroup *memcg; int id; atomic_t refcnt; + bool dead; + struct work_struct cache_shrinker; #ifdef CONFIG_SLAB /* Original cache parameters, used when creating a memcg cache */ diff --git a/include/linux/slub_def.h b/include/linux/slub_def.h index ba9c68b..c1428ee 100644 --- a/include/linux/slub_def.h +++ b/include/linux/slub_def.h @@ -135,6 +135,14 @@ static inline bool slab_is…
creator: Glauber Costa
date: 2012-05-25T13:03:42-00:00

[PATCH v3 23/28] slab: 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. We also use this to propagate /proc/slabinfo settings to all the children of a cache, when, for example, changing its batchsize. Code is inspired by Suleiman's, with adaptations to the patchset and simplifications by me. 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 | 13 ++++++++- mm/slab.c | 61 +++++++++++++++++++++++++++++++++++++++++++- 4 files changed, 73 insertions(+), 3 deletions(-) diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h index df049e1..63113de 100644 --- a/include/linux/memcontrol.h +++ b/include/linux/memcontrol.h @@ -465,6 +465,7 @@ extern struct static_key mem_cgroup_kmem_enabled_key; #define mem_cgroup_kmem_on static_key_false(&mem_cgroup_kmem_enabled_key) 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 mem_cgroup_register_cache(struct mem_cgroup *memcg, struct kmem_cache *s) diff --git a/include/linux/slab.h b/include/linux/slab.h index 25f073e..714aeab 100644 --- a/include/linux/slab.h +++ b/include/linux/slab.h @@ -172,6 +172,7 @@ struct mem_cgroup_cache_params { struct kmem_cache *parent; #endif 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 e2576c5..08f3c3e 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -542,10 +542,11 @@ void mem_cgroup_re…
creator: Glauber Costa
date: 2012-05-25T13:03:43-00:00

[PATCH v3 24/28] memcg: Per-memcg memory.kmem.slabinfo file.
type: item
description: From: Suleiman Souhlal <ssouhlal@FreeBSD.org> This file shows all the kmem_caches used by a memcg. Signed-off-by: Suleiman Souhlal <suleiman@google.com> --- include/linux/slab.h | 1 + mm/memcontrol.c | 17 ++++++++++ mm/slab.c | 87 ++++++++++++++++++++++++++++++++++++------------- mm/slub.c | 5 +++ 4 files changed, 87 insertions(+), 23 deletions(-) diff --git a/include/linux/slab.h b/include/linux/slab.h index 714aeab..f2f51d8 100644 --- a/include/linux/slab.h +++ b/include/linux/slab.h @@ -333,6 +333,7 @@ extern void *__kmalloc_track_caller(size_t, gfp_t, unsigned long); #define MAX_KMEM_CACHE_TYPES 400 extern struct kmem_cache *kmem_cache_dup(struct mem_cgroup *memcg, struct kmem_cache *cachep); +extern int mem_cgroup_slabinfo(struct mem_cgroup *mem, struct seq_file *m); #else #define MAX_KMEM_CACHE_TYPES 0 #endif /* CONFIG_CGROUP_MEM_RES_CTLR_KMEM */ diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 08f3c3e..3e99c69 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -5229,6 +5229,19 @@ static int mem_control_numa_stat_open(struct inode *unused, struct file *file) #endif /* CONFIG_NUMA */ #ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM +static int mem_cgroup_slabinfo_show(struct cgroup *cgroup, struct cftype *ctf, + struct seq_file *m) +{ + struct mem_cgroup *mem; + + mem = mem_cgroup_from_cont(cgroup); + + if (mem == root_mem_cgroup) + mem = NULL; + + return mem_cgroup_slabinfo(mem, m); +} + static struct cftype kmem_cgroup_files[] = { { .name = "kmem.limit_in_bytes", @@ -5253,6 +5266,10 @@ static struct cftype kmem_cgroup_files[] = { .trigger = mem_cgroup_reset, .read = mem_cgroup_read, }, + { + .name = "kmem.slabinfo", + .read_seq_string = mem_cgroup_slabinfo_show, + }, {}, }; diff --git a/mm/slab.c b/mm/slab.c index cb409ae..2f9cf92 100644 --- a/mm/slab.c +++ b/mm/slab.c @@ -4550,21 +4550,26 @@ static void s_stop(struct seq_file *m, void *p) mutex_unlock(&cache_chain_mutex); } -static int s_show(struct seq_file *m, void *p) -{ - struct kmem_cache *cachep = list_en…
creator: Glauber Costa
date: 2012-05-25T13:03:44-00:00

[PATCH v3 25/28] slub: create slabinfo file for memcg
type: item
description: This patch implements mem_cgroup_slabinfo() for the slub. With that, we can also probe the used caches for it. 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/slub.c | 27 +++++++++++++++++++++++++++ 1 files changed, 27 insertions(+), 0 deletions(-) diff --git a/mm/slub.c b/mm/slub.c index c8a8cab..4c29e5f 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -4113,6 +4113,33 @@ struct kmem_cache *kmem_cache_dup(struct mem_cgroup *memcg, int mem_cgroup_slabinfo(struct mem_cgroup *memcg, struct seq_file *m) { + struct kmem_cache *s; + int node; + unsigned long nr_objs = 0; + unsigned long nr_free = 0; + + seq_printf(m, "# name <active_objs> <num_objs> <objsize>\n"); + + down_read(&slub_lock); + list_for_each_entry(s, &slab_caches, list) { + if (s->memcg_params.memcg != memcg) + continue; + + for_each_online_node(node) { + struct kmem_cache_node *n = get_node(s, node); + + if (!n) + continue; + + nr_objs += atomic_long_read(&n->total_objects); + nr_free += count_partial(n, count_free); + } + + seq_printf(m, "%-17s %6lu %6lu %6u\n", s->name, + nr_objs - nr_free, nr_objs, s->size); + } + up_read(&slub_lock); + return 0; } #endif -- 1.7.7.6
creator: Glauber Costa
date: 2012-05-25T13:03:45-00:00

[PATCH v3 26/28] slub: track all children of a kmem cache
type: item
description: When we destroy a cache (like for instance, if we're unloading a module) we need to go through the list of memcg caches and destroy them as well. The caches are expected to be empty by themselves, so nothing is changed here. All previous guarantees are kept and no new guarantees are given. So given all memcg caches are expected to be empty - even though they are likely to be hanging around in the system, we just need to scan a list of sibling caches, and destroy each one of them. This is very similar to the work done by Suleiman 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> --- mm/slub.c | 64 ++++++++++++++++++++++++++++++++++++++++++++++++++++-------- 1 files changed, 55 insertions(+), 9 deletions(-) diff --git a/mm/slub.c b/mm/slub.c index 4c29e5f..8151353 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -3254,6 +3254,54 @@ static inline int kmem_cache_close(struct kmem_cache *s) return 0; } +static void kmem_cache_destroy_unlocked(struct kmem_cache *s) +{ + mem_cgroup_release_cache(s); + if (kmem_cache_close(s)) { + printk(KERN_ERR + "SLUB %s: %s called for cache that still has objects.\n", + s->name, __func__); + dump_stack(); + } + + if (s->flags & SLAB_DESTROY_BY_RCU) + rcu_barrier(); + sysfs_slab_remove(s); +} + +static void kmem_cache_destroy_memcg_children(struct kmem_cache *s) +{ +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM + struct mem_cgroup_cache_params *p, *tmp, *this; + struct kmem_cache *c; + int id = s->memcg_params.id; + + /* Not a parent cache */ + if (id == -1) + return ; + + this = &s->memcg_params; + mem_cgroup_flush_cache_create_queue(); + list_for_each_entry_safe(p, tmp, &this->sibling_list, sibling_list) { + c = container_of(p, struct kmem_cache, memcg_params); + /* We never added the …
creator: Glauber Costa
date: 2012-05-25T13:03:46-00:00

[PATCH v3 27/28] memcg: propagate kmem limiting information to children
type: item
description: The current memcg slab cache management fails to present satisfatory hierarchical behavior in the following scenario: -> /cgroups/memory/A/B/C * kmem limit set at A * A and B empty taskwise * bash in C does find / Because kmem_accounted is a boolean that was not set for C, no accounting would be done. This is, however, not what we expect. The basic idea, is that when a cgroup is limited, we walk the tree upwards (something Kame and I already thought about doing for other purposes), and make sure that we store the information about the parent being limited in kmem_accounted (that is turned into a bitmap: two booleans would not be space efficient). The code for that is taken from sched/core.c. My reasons for not putting it into a common place is to dodge the type issues that would arise from a common implementation between memcg and the scheduler - but I think that it should ultimately happen, so if you want me to do it now, let me know. We do the reverse operation when a formerly limited cgroup becomes unlimited. 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/memcontrol.c | 147 +++++++++++++++++++++++++++++++++++++++++++++++++------ 1 files changed, 131 insertions(+), 16 deletions(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 3e99c69..7572cb1 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -259,6 +259,9 @@ struct mem_cgroup { * the counter to account for kernel memory usage. */ struct res_counter kmem; + + struct list_head children; + struct list_head siblings; /* * Per cgroup active and inactive list, similar to the * per zone LRU lists. @@ -274,7 +277,11 @@ struct mem_cgroup { * Should the accounting and control be hierarchical, per subtree? */ bool use_hierarchy; - bool kmem_accounted; + …
creator: Glauber Costa
date: 2012-05-25T13:03:47-00:00

[PATCH v3 28/28] Documentation: add documentation for slab tracker for memcg
type: item
description: In a separate patch, to aid reviewers. 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> CC: Randy Dunlap <rdunlap@xenotime.net> --- Documentation/cgroups/memory.txt | 33 +++++++++++++++++++++++++++++++++ 1 files changed, 33 insertions(+), 0 deletions(-) diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt index 4c95c00..9accaa1 100644 --- a/Documentation/cgroups/memory.txt +++ b/Documentation/cgroups/memory.txt @@ -75,6 +75,12 @@ Brief summary of control files. memory.kmem.tcp.limit_in_bytes # set/show hard limit for tcp buf memory memory.kmem.tcp.usage_in_bytes # show current tcp buf memory allocation + memory.kmem.limit_in_bytes # set/show hard limit for general kmem memory + memory.kmem.usage_in_bytes # show current general kmem memory allocation + memory.kmem.failcnt # show current number of kmem limit hits + memory.kmem.max_usage_in_bytes # show max kmem usage + memory.kmem.slabinfo # show cgroup-specific slab usage information + 1. History The memory controller has a long history. A request for comments for the memory @@ -271,6 +277,14 @@ cgroup may or may not be accounted. Currently no soft limit is implemented for kernel memory. It is future work to trigger slab reclaim when those limits are reached. +Kernel memory is not accounted until it is limited. Users that want to just +track kernel memory usage can set the limit value to a big enough value so +the limit is guaranteed to never hit. A kernel memory limit bigger than the +current memory limit will have this effect as well. + +This guarantes that this extension is backwards compatible to any previous +memory cgroup version. + 2.7.1 Current Kernel Memory resources accounted * sockets memory pressure: some sockets protocols hav…
creator: Glauber Costa
date: 2012-05-25T13:03:48-00:00

Re: [PATCH v3 00/28] kmem limitation for memcg
type: item
description: On Fri 25-05-12 17:03:20, Glauber Costa wrote: > I believe some of the early patches here are already in some trees around. > I don't know who should pick this, so if everyone agrees with what's in here, > please just ack them and tell me which tree I should aim for (-mm? Hocko's?) > and I'll rebase it. memcg-devel tree is only to make development easier. Everything that applies on top of this tree should be applicable to both -mm and linux-next. So the patches should go via traditional Andrew's channel. -- Michal Hocko SUSE Labs SUSE LINUX s.r.o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic
creator: Michal Hocko
date: 2012-05-25T13:34:41-00:00

Re: [PATCH v3 00/28] kmem limitation for memcg
type: item
description: On Fri, 25 May 2012, Michal Hocko wrote: > On Fri 25-05-12 17:03:20, Glauber Costa wrote: > > I believe some of the early patches here are already in some trees around. > > I don't know who should pick this, so if everyone agrees with what's in here, > > please just ack them and tell me which tree I should aim for (-mm? Hocko's?) > > and I'll rebase it. > > memcg-devel tree is only to make development easier. Everything that > applies on top of this tree should be applicable to both -mm and > linux-next. > So the patches should go via traditional Andrew's channel. It would be best to merge these with my patchset to extract common code from the allocators. The modifications of individual slab allocators would then be not necessary anymore and it would save us a lot of work.
creator: Christoph Lameter
date: 2012-05-25T14:34:43-00:00

Re: [PATCH v3 00/28] kmem limitation for memcg
type: item
description: On 05/25/2012 06:34 PM, Christoph Lameter wrote: > On Fri, 25 May 2012, Michal Hocko wrote: > >> On Fri 25-05-12 17:03:20, Glauber Costa wrote: >>> I believe some of the early patches here are already in some trees around. >>> I don't know who should pick this, so if everyone agrees with what's in here, >>> please just ack them and tell me which tree I should aim for (-mm? Hocko's?) >>> and I'll rebase it. >> >> memcg-devel tree is only to make development easier. Everything that >> applies on top of this tree should be applicable to both -mm and >> linux-next. >> So the patches should go via traditional Andrew's channel. > > It would be best to merge these with my patchset to extract common code > from the allocators. The modifications of individual slab allocators would > then be not necessary anymore and it would save us a lot of work. > Some of them would not, some of them would still be. But also please note that the patches here that deal with differences between allocators are usually the low hanging fruits compared to the rest. I agree that long term it not only better, but inevitable, if we are going to merge both. But right now, I think we should agree with the implementation itself - so if you have any comments on how I am handling these, I'd be happy to hear. Then we can probably set up a tree that does both, or get your patches merged and I'll rebase, etc.
creator: Glauber Costa
date: 2012-05-28T08:32:28-00:00

Re: [PATCH v3 12/28] slab: pass memcg parameter to kmem_cache_create
type: item
description: On Fri, 25 May 2012, Glauber Costa wrote: > index 06e4a3e..7c0cdd6 100644 > --- a/include/linux/slab_def.h > +++ b/include/linux/slab_def.h > @@ -102,6 +102,13 @@ struct kmem_cache { > */ > }; > > +static inline void store_orig_align(struct kmem_cache *cachep, int orig_align) > +{ > +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM > + cachep->memcg_params.orig_align = orig_align; > +#endif > +} > + Why do you need to store the original alignment? Is the calculated alignment not enough? > +++ b/mm/slab.c > @@ -1729,6 +1729,31 @@ void __init kmem_cache_init_late(void) > */ > } > > +static int __init memcg_slab_register_all(void) > +{ > +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM > + struct kmem_cache *cachep; > + struct cache_sizes *sizes; > + > + sizes = malloc_sizes; > + > + while (sizes->cs_size != ULONG_MAX) { > + if (sizes->cs_cachep) > + mem_cgroup_register_cache(NULL, sizes->cs_cachep); > + if (sizes->cs_dmacachep) > + mem_cgroup_register_cache(NULL, sizes->cs_dmacachep); > + sizes++; > + } > + > + mutex_lock(&cache_chain_mutex); > + list_for_each_entry(cachep, &cache_chain, next) > + mem_cgroup_register_cache(NULL, cachep); > + > + mutex_unlock(&cache_chain_mutex); > +#endif /* CONFIG_CGROUP_MEM_RES_CTLR_KMEM */ > + return 0; > +} Ok this only duplicates the kmalloc arrays. Why not the others? > @@ -2331,7 +2350,7 @@ kmem_cache_create (const char *name, size_t size, size_t align, > continue; > } > > - if (!strcmp(pc->name, name)) { > + if (!memcg && !strcmp(pc->name, name)) { > printk(KERN_ERR > "kmem_cache_create: duplicate cache %s\n", name); > dump_stack(); This implementation means that duplicate cache detection will no longer work within a cgroup? > @@ -2543,7 +2564,12 @@ kmem_cache_create (const char *name, size_t size, size_t align, > cachep->ctor = ctor; > cachep->name = name; > > + if (g_cpucache_up >= FULL) > + mem_cgroup_register_cache(memcg, cachep); What happens if a cgroup was active during creation of slab xxy but then a process running in a different cgroup…
creator: Christoph Lameter
date: 2012-05-29T14:27:52-00:00

Re: [PATCH v3 13/28] slub: create duplicate cache
type: item
description: On Fri, 25 May 2012, Glauber Costa wrote: > index dacd1fb..4689034 100644 > --- a/mm/memcontrol.c > +++ b/mm/memcontrol.c > @@ -467,6 +467,23 @@ struct cg_proto *tcp_proto_cgroup(struct mem_cgroup *memcg) > EXPORT_SYMBOL(tcp_proto_cgroup); > #endif /* CONFIG_INET */ > > +char *mem_cgroup_cache_name(struct mem_cgroup *memcg, struct kmem_cache *cachep) > +{ > + char *name; > + struct dentry *dentry; > + > + rcu_read_lock(); > + dentry = rcu_dereference(memcg->css.cgroup->dentry); > + rcu_read_unlock(); > + > + BUG_ON(dentry == NULL); > + > + name = kasprintf(GFP_KERNEL, "%s(%d:%s)", > + cachep->name, css_id(&memcg->css), dentry->d_name.name); > + > + return name; > +} Function allocates a string that is supposed to be disposed of by the caller. That needs to be documented and maybe even the name needs to reflect that. > --- a/mm/slub.c > +++ b/mm/slub.c > @@ -4002,6 +4002,38 @@ struct kmem_cache *kmem_cache_create(const char *name, size_t size, > } > EXPORT_SYMBOL(kmem_cache_create); > > +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM > +struct kmem_cache *kmem_cache_dup(struct mem_cgroup *memcg, > + struct kmem_cache *s) > +{ > + char *name; > + struct kmem_cache *new; > + > + name = mem_cgroup_cache_name(memcg, s); > + if (!name) > + return NULL; > + > + new = kmem_cache_create_memcg(memcg, name, s->objsize, s->align, > + (s->allocflags & ~SLAB_PANIC), s->ctor); Hmmm... A full duplicate of the slab cache? We may have many sparsely used portions of the per node and per cpu structure as a result. > + * prevent it from being deleted. If kmem_cache_destroy() is > + * called for the root cache before we call it for a child cache, > + * it will be queued for destruction when we finally drop the > + * reference on the child cache. > + */ > + if (new) { > + down_write(&slub_lock); > + s->refcount++; > + up_write(&slub_lock); > + } Why do you need to increase the refcount? You made a full copy right?
creator: Christoph Lameter
date: 2012-05-29T14:36:55-00:00

Re: [PATCH v3 15/28] slub: always get the cache from its page in kfree
type: item
description: On Fri, 25 May 2012, Glauber Costa wrote: > struct page already have this information. If we start chaining > caches, this information will always be more trustworthy than > whatever is passed into the function Yes but the lookup of the page struct also costs some cycles. SLAB in !NUMA mode and SLOB avoid these lookups and can improve their freeing speed because of that. > diff --git a/mm/slub.c b/mm/slub.c > index 0eb9e72..640872f 100644 > --- a/mm/slub.c > +++ b/mm/slub.c > @@ -2598,10 +2598,14 @@ redo: > void kmem_cache_free(struct kmem_cache *s, void *x) > { > struct page *page; > + bool slab_match; > > page = virt_to_head_page(x); > > - slab_free(s, page, x, _RET_IP_); > + slab_match = (page->slab == s) | slab_is_parent(page->slab, s); > + VM_BUG_ON(!slab_match); Why add a slab_match bool if you do not really need it?
creator: Christoph Lameter
date: 2012-05-29T14:42:03-00:00

Re: [PATCH v3 16/28] memcg: kmem controller charge/uncharge infrastructure
type: item
description: On Fri, 25 May 2012, Glauber Costa wrote: > --- a/init/Kconfig > +++ b/init/Kconfig > @@ -696,7 +696,7 @@ config CGROUP_MEM_RES_CTLR_SWAP_ENABLED > then swapaccount=0 does the trick). > config CGROUP_MEM_RES_CTLR_KMEM > bool "Memory Resource Controller Kernel Memory accounting (EXPERIMENTAL)" > - depends on CGROUP_MEM_RES_CTLR && EXPERIMENTAL > + depends on CGROUP_MEM_RES_CTLR && EXPERIMENTAL && !SLOB > default n Ok so SLOB is not supported at all.
creator: Christoph Lameter
date: 2012-05-29T14:47:38-00:00

Re: [PATCH v3 18/28] slub: charge allocation to a memcg
type: item
description: On Fri, 25 May 2012, Glauber Costa wrote: > This patch charges allocation of a slab object to a particular > memcg. I am wondering why you need all the other patches. The simplest approach would just to hook into page allocation and freeing from the slab allocators as done here and charge to the currently active cgroup. This avoids all the duplication of slab caches and per node as well as per cpu structures. A certain degree of fuzziness cannot be avoided given that objects are cached and may be served to multiple cgroups. If that can be tolerated then the rest would be just like this patch which could be made more simple and non intrusive.
creator: Christoph Lameter
date: 2012-05-29T14:51:20-00:00

Re: [PATCH v3 19/28] slab: per-memcg accounting of slab caches
type: item
description: On Fri, 25 May 2012, Glauber Costa wrote: > This patch charges allocation of a slab object to a particular > memcg. Ok so a requirement is to support tracking of individual slab objects to cgroups? That is going to be quite expensive since it will touch the hotpaths.
creator: Christoph Lameter
date: 2012-05-29T14:52:59-00:00

Re: [PATCH v3 00/28] kmem limitation for memcg
type: item
description: On Mon, 28 May 2012, Glauber Costa wrote: > > It would be best to merge these with my patchset to extract common code > > from the allocators. The modifications of individual slab allocators would > > then be not necessary anymore and it would save us a lot of work. > > > Some of them would not, some of them would still be. But also please note that > the patches here that deal with differences between allocators are usually the > low hanging fruits compared to the rest. > > I agree that long term it not only better, but inevitable, if we are going to > merge both. > > But right now, I think we should agree with the implementation itself - so if > you have any comments on how I am handling these, I'd be happy to hear. Then > we can probably set up a tree that does both, or get your patches merged and > I'll rebase, etc. Just looked over the patchset and its quite intrusive. I have never been fond of cgroups (IMHO hardware needs to be partitioned at physical boundaries) so I have not too much insight into what is going on in that area. The idea to just duplicate the caches leads to some weird stuff like the refcounting and the recovery of the arguments used during slab creation. I think it may be simplest to only account for the pages used by a slab in a memcg. That code could be added to the functions in the slab allocators that interface with the page allocators. Those are not that performance critical and would do not much harm. If you need per object accounting then the cleanest solution would be to duplicate the per node arrays per memcg (or only the statistics) and have the kmem_cache structure only once in memory. Its best if information is only in one place for design and for performance.
creator: Christoph Lameter
date: 2012-05-29T15:07:39-00:00

Re: [PATCH v3 00/28] kmem limitation for memcg
type: item
description: On 05/29/2012 07:07 PM, Christoph Lameter wrote: > On Mon, 28 May 2012, Glauber Costa wrote: > >>> It would be best to merge these with my patchset to extract common code >>> from the allocators. The modifications of individual slab allocators would >>> then be not necessary anymore and it would save us a lot of work. >>> >> Some of them would not, some of them would still be. But also please note that >> the patches here that deal with differences between allocators are usually the >> low hanging fruits compared to the rest. >> >> I agree that long term it not only better, but inevitable, if we are going to >> merge both. >> >> But right now, I think we should agree with the implementation itself - so if >> you have any comments on how I am handling these, I'd be happy to hear. Then >> we can probably set up a tree that does both, or get your patches merged and >> I'll rebase, etc. > > Just looked over the patchset and its quite intrusive. Thank you very much, Christoph, appreciate it. > I have never been > fond of cgroups (IMHO hardware needs to be partitioned at physical > boundaries) so I have not too much insight into what is going on in that > area. There is certainly a big market for that, and certainly a big market for what we're doing as well. So there are users interested in Containers technology, and I don't really see it as "partitioning it here" vs "partitioning there". It's just different. Moreover, not everyone doing cgroups are doing containers. Some people are isolating a service, or a paticular job. I agree it is an intrusive change, but it used to be even more. I did my best to diminish its large spread. > The idea to just duplicate the caches leads to some weird stuff like the > refcounting and the recovery of the arguments used during slab creation. The refcounting is only needed so we are sure the parent cache won't go away without the child caches going away. I can try to find a better way to do that, specifically. > > I think it may be simple…
creator: Glauber Costa
date: 2012-05-29T15:44:54-00:00

Re: [PATCH v3 12/28] slab: pass memcg parameter to kmem_cache_create
type: item
description: On 05/29/2012 06:27 PM, Christoph Lameter wrote: > On Fri, 25 May 2012, Glauber Costa wrote: > >> index 06e4a3e..7c0cdd6 100644 >> --- a/include/linux/slab_def.h >> +++ b/include/linux/slab_def.h >> @@ -102,6 +102,13 @@ struct kmem_cache { >> */ >> }; >> >> +static inline void store_orig_align(struct kmem_cache *cachep, int orig_align) >> +{ >> +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM >> + cachep->memcg_params.orig_align = orig_align; >> +#endif >> +} >> + > > Why do you need to store the original alignment? Is the calculated > alignment not enough? I think this one can go. You are right. >> +++ b/mm/slab.c >> @@ -1729,6 +1729,31 @@ void __init kmem_cache_init_late(void) >> */ >> } >> >> +static int __init memcg_slab_register_all(void) >> +{ >> +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM >> + struct kmem_cache *cachep; >> + struct cache_sizes *sizes; >> + >> + sizes = malloc_sizes; >> + >> + while (sizes->cs_size != ULONG_MAX) { >> + if (sizes->cs_cachep) >> + mem_cgroup_register_cache(NULL, sizes->cs_cachep); >> + if (sizes->cs_dmacachep) >> + mem_cgroup_register_cache(NULL, sizes->cs_dmacachep); >> + sizes++; >> + } >> + >> + mutex_lock(&cache_chain_mutex); >> + list_for_each_entry(cachep,&cache_chain, next) >> + mem_cgroup_register_cache(NULL, cachep); >> + >> + mutex_unlock(&cache_chain_mutex); >> +#endif /* CONFIG_CGROUP_MEM_RES_CTLR_KMEM */ >> + return 0; >> +} > > Ok this only duplicates the kmalloc arrays. Why not the others? It does duplicate the others. First it does a while look on the kmalloc caches, then a list_for_each_entry in the rest. You probably missed it. >> @@ -2331,7 +2350,7 @@ kmem_cache_create (const char *name, size_t size, size_t align, >> continue; >> } >> >> - if (!strcmp(pc->name, name)) { >> + if (!memcg&& !strcmp(pc->name, name)) { >> printk(KERN_ERR >> "kmem_cache_create: duplicate cache %s\n", name); >> dump_stack(); > > This implementation means that duplicate cache detection will no longer > work within a cgroup? For the slab, yes. For …
creator: Glauber Costa
date: 2012-05-29T15:50:39-00:00

Re: [PATCH v3 13/28] slub: create duplicate cache
type: item
description: On 05/29/2012 06:36 PM, Christoph Lameter wrote: > On Fri, 25 May 2012, Glauber Costa wrote: > >> index dacd1fb..4689034 100644 >> --- a/mm/memcontrol.c >> +++ b/mm/memcontrol.c >> @@ -467,6 +467,23 @@ struct cg_proto *tcp_proto_cgroup(struct mem_cgroup *memcg) >> EXPORT_SYMBOL(tcp_proto_cgroup); >> #endif /* CONFIG_INET */ >> >> +char *mem_cgroup_cache_name(struct mem_cgroup *memcg, struct kmem_cache *cachep) >> +{ >> + char *name; >> + struct dentry *dentry; >> + >> + rcu_read_lock(); >> + dentry = rcu_dereference(memcg->css.cgroup->dentry); >> + rcu_read_unlock(); >> + >> + BUG_ON(dentry == NULL); >> + >> + name = kasprintf(GFP_KERNEL, "%s(%d:%s)", >> + cachep->name, css_id(&memcg->css), dentry->d_name.name); >> + >> + return name; >> +} > > Function allocates a string that is supposed to be disposed of by the > caller. That needs to be documented and maybe even the name needs to > reflect that. Okay, I can change it. >> --- a/mm/slub.c >> +++ b/mm/slub.c >> @@ -4002,6 +4002,38 @@ struct kmem_cache *kmem_cache_create(const char *name, size_t size, >> } >> EXPORT_SYMBOL(kmem_cache_create); >> >> +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM >> +struct kmem_cache *kmem_cache_dup(struct mem_cgroup *memcg, >> + struct kmem_cache *s) >> +{ >> + char *name; >> + struct kmem_cache *new; >> + >> + name = mem_cgroup_cache_name(memcg, s); >> + if (!name) >> + return NULL; >> + >> + new = kmem_cache_create_memcg(memcg, name, s->objsize, s->align, >> + (s->allocflags& ~SLAB_PANIC), s->ctor); > > Hmmm... A full duplicate of the slab cache? We may have many sparsely > used portions of the per node and per cpu structure as a result. I've already commented on patch 0, but I will repeat it here. This approach leads to more fragmentation, yes, but this is exactly to be less intrusive. With a full copy, all I need to do is: 1) relay the allocation to the right cache. 2) account for a new page when it is needed. How does the cache work from inside? I don't care. Accounting pages seems jus…
creator: Glauber Costa
date: 2012-05-29T15:56:23-00:00

Re: [PATCH v3 15/28] slub: always get the cache from its page in kfree
type: item
description: On 05/29/2012 06:42 PM, Christoph Lameter wrote: > On Fri, 25 May 2012, Glauber Costa wrote: > >> struct page already have this information. If we start chaining >> caches, this information will always be more trustworthy than >> whatever is passed into the function > > Yes but the lookup of the page struct also costs some cycles. SLAB in > !NUMA mode and SLOB avoid these lookups and can improve their freeing > speed because of that. But for our case, I don't really see a way around. What I can do, is wrap it further, so when we're not using it, code goes exactly the same way as before, instead of always calculating the page. Would it be better? >> diff --git a/mm/slub.c b/mm/slub.c >> index 0eb9e72..640872f 100644 >> --- a/mm/slub.c >> +++ b/mm/slub.c >> @@ -2598,10 +2598,14 @@ redo: >> void kmem_cache_free(struct kmem_cache *s, void *x) >> { >> struct page *page; >> + bool slab_match; >> >> page = virt_to_head_page(x); >> >> - slab_free(s, page, x, _RET_IP_); >> + slab_match = (page->slab == s) | slab_is_parent(page->slab, s); >> + VM_BUG_ON(!slab_match); > > Why add a slab_match bool if you do not really need it? style. I find aux variables a very human readable way to deal with the 80-col limitation.
creator: Glauber Costa
date: 2012-05-29T15:59:47-00:00

Re: [PATCH v3 16/28] memcg: kmem controller charge/uncharge infrastructure
type: item
description: On 05/29/2012 06:47 PM, Christoph Lameter wrote: > On Fri, 25 May 2012, Glauber Costa wrote: > >> --- a/init/Kconfig >> +++ b/init/Kconfig >> @@ -696,7 +696,7 @@ config CGROUP_MEM_RES_CTLR_SWAP_ENABLED >> then swapaccount=0 does the trick). >> config CGROUP_MEM_RES_CTLR_KMEM >> bool "Memory Resource Controller Kernel Memory accounting (EXPERIMENTAL)" >> - depends on CGROUP_MEM_RES_CTLR&& EXPERIMENTAL >> + depends on CGROUP_MEM_RES_CTLR&& EXPERIMENTAL&& !SLOB >> default n > > Ok so SLOB is not supported at all. > Yes, at least I see no reason to.
creator: Glauber Costa
date: 2012-05-29T16:00:23-00:00

Re: [PATCH v3 00/28] kmem limitation for memcg
type: item
description: On Tue, 29 May 2012, Glauber Costa wrote: > > I think it may be simplest to only account for the pages used by a slab in > > a memcg. That code could be added to the functions in the slab allocators > > that interface with the page allocators. Those are not that performance > > critical and would do not much harm. > > No, I don't think so. Well, accounting the page is easy, but when we do a new > allocation, we need to match a process to its correspondent page. This will > likely lead to flushing the internal cpu caches of the slub, for instance, > hurting performance. That is because once we allocate a page, all objects on > that page need to belong to the same cgroup. Matching a process to its page is a complex thing even for pages used by userspace. How can you make sure that all objects on a page belong to the same cgroup? There are various kernel allocations that have uses far beyond a single context. There is already a certain degree of fuzziness there and we tolerate that in other contexts as well. > Also, you talk about intrusiveness, accounting pages is a lot more intrusive, > since then you need to know a lot about the internal structure of each cache. > Having the cache replicated has exactly the effect of isolating it better. Why would you need to know about the internal structure? Just get the current process context and use the cgroup that is readily available there to account for the pages. > > If you need per object accounting then the cleanest solution would be to > > duplicate the per node arrays per memcg (or only the statistics) and have > > the kmem_cache structure only once in memory. > > No, it's all per-page. Nothing here is per-object, maybe you misunderstood > something? There are free/used object counters in each page. You could account for objects in the l3 lists or kmem_cache_node strcut and thereby avoid having to deal with the individual objects at the per cpu level.
creator: Christoph Lameter
date: 2012-05-29T16:01:03-00:00

Re: [PATCH v3 13/28] slub: create duplicate cache
type: item
description: On Tue, 29 May 2012, Glauber Costa wrote: > Accounting pages seems just crazy to me. If new allocators come in the future, > organizing the pages in a different way, instead of patching it here and > there, we need to totally rewrite this. Quite to the contrary. We could either pass a THIS_IS_A_SLAB page flag to the page allocator call or have a special call that does the accounting and then calls the page allocator. The code could be completely in cgroups. There would be no changes to the allocators aside from setting the flag or calling the alternate page allocator functions. > > Why do you need to increase the refcount? You made a full copy right? > > Yes, but I don't want this copy to go away while we have other caches around. You copied all metadata so what is there that you would still need should the other copy go away? > So, in the memcg internals, I used a different reference counter, to avoid > messing with this one. I could use that, and leave the original refcnt alone. > Would you prefer this? The refcounter is really not the issue. I am a bit worried about the various duplicate features here and there. The approach is not tightened down yet.
creator: Christoph Lameter
date: 2012-05-29T16:05:16-00:00

Re: [PATCH v3 18/28] slub: charge allocation to a memcg
type: item
description: On 05/29/2012 06:51 PM, Christoph Lameter wrote: > On Fri, 25 May 2012, Glauber Costa wrote: > >> This patch charges allocation of a slab object to a particular >> memcg. > > I am wondering why you need all the other patches. The simplest approach > would just to hook into page allocation and freeing from the slab > allocators as done here and charge to the currently active cgroup. This > avoids all the duplication of slab caches and per node as well as per cpu > structures. A certain degree of fuzziness cannot be avoided given that > objects are cached and may be served to multiple cgroups. If that can be > tolerated then the rest would be just like this patch which could be made > more simple and non intrusive. > Just hooking into the page allocation only works for caches with very big objects. For all the others, we need to relay the process to the correct cache. Some objects may be shared, yes, but in reality most won't. Let me give you an example: We track task_struct here. So as a nice side effect of this, a fork bomb will be killed because it will not be able to allocate any further. But if we're accounting only at page allocation time, it is quite possible to come up with a pattern while I always let other cgroups pay the price for the page, but I will be the one filling it. Having an eventual dentry, for instance, shared among caches, is okay. But the main use case is for process in different cgroups dealing with totally different parts of the filesystem. So we can't really afford to charge to the process touching the nth object where n is the number of objects per page. We need to relay it to the right one.
creator: Glauber Costa
date: 2012-05-29T16:06:45-00:00

Re: [PATCH v3 19/28] slab: per-memcg accounting of slab caches
type: item
description: On 05/29/2012 06:52 PM, Christoph Lameter wrote: > On Fri, 25 May 2012, Glauber Costa wrote: > >> > This patch charges allocation of a slab object to a particular >> > memcg. > Ok so a requirement is to support tracking of individual slab > objects to cgroups? That is going to be quite expensive since it will > touch the hotpaths. > No, we track pages. But all the objects in the page belong to the same cgroup.
creator: Glauber Costa
date: 2012-05-29T16:07:09-00:00

Re: [PATCH v3 19/28] slab: per-memcg accounting of slab caches
type: item
description: On 05/29/2012 08:07 PM, Glauber Costa wrote: > On 05/29/2012 06:52 PM, Christoph Lameter wrote: >> On Fri, 25 May 2012, Glauber Costa wrote: >> >>> > This patch charges allocation of a slab object to a particular >>> > memcg. >> Ok so a requirement is to support tracking of individual slab >> objects to cgroups? That is going to be quite expensive since it will >> touch the hotpaths. >> > > No, we track pages. But all the objects in the page belong to the same > cgroup. > Also, please note the following: The code that relays us to the right cache, is wrapped inside a static branch. Whoever is not using more than the root cgroup, will not suffer a single bit. If you are, but your process is in the right cgroup, you will unfortunately pay function call penalty(*), but the code will make and effort to detect that as early as possible and resume. (*) Not even then if you fall in the following categories, that are resolved inline: + if (!current->mm) + return cachep; + if (in_interrupt()) + return cachep; + if (gfp & __GFP_NOFAIL) + return cachep;
creator: Glauber Costa
date: 2012-05-29T16:13:28-00:00

Re: [PATCH v3 12/28] slab: pass memcg parameter to kmem_cache_create
type: item
description: On Tue, 29 May 2012, Glauber Costa wrote: > > Ok this only duplicates the kmalloc arrays. Why not the others? > > It does duplicate the others. > > First it does a while look on the kmalloc caches, then a list_for_each_entry > in the rest. You probably missed it. There is no need to separately duplicate the kmalloc_caches. Those are included on the cache_chain. > > > @@ -2543,7 +2564,12 @@ kmem_cache_create (const char *name, size_t size, > > > size_t align, > > > cachep->ctor = ctor; > > > cachep->name = name; > > > > > > + if (g_cpucache_up>= FULL) > > > + mem_cgroup_register_cache(memcg, cachep); > > > > What happens if a cgroup was active during creation of slab xxy but > > then a process running in a different cgroup uses that slab to allocate > > memory? Is it charged to the first cgroup? > > I don't see this situation ever happening. kmem_cache_create, when called > directly, will always create a global cache. It doesn't matter which cgroups > are or aren't active at this time or any other. We create copies per-cgroup, > but we create it lazily, when someone will touch it. How do you detect that someone is touching it?
creator: Christoph Lameter
date: 2012-05-29T16:33:17-00:00

Re: [PATCH v3 12/28] slab: pass memcg parameter to kmem_cache_create
type: item
description: On 05/29/2012 08:33 PM, Christoph Lameter wrote: > On Tue, 29 May 2012, Glauber Costa wrote: > >>> Ok this only duplicates the kmalloc arrays. Why not the others? >> >> It does duplicate the others. >> >> First it does a while look on the kmalloc caches, then a list_for_each_entry >> in the rest. You probably missed it. > > There is no need to separately duplicate the kmalloc_caches. Those are > included on the cache_chain. > >>>> @@ -2543,7 +2564,12 @@ kmem_cache_create (const char *name, size_t size, >>>> size_t align, >>>> cachep->ctor = ctor; >>>> cachep->name = name; >>>> >>>> + if (g_cpucache_up>= FULL) >>>> + mem_cgroup_register_cache(memcg, cachep); >>> >>> What happens if a cgroup was active during creation of slab xxy but >>> then a process running in a different cgroup uses that slab to allocate >>> memory? Is it charged to the first cgroup? >> >> I don't see this situation ever happening. kmem_cache_create, when called >> directly, will always create a global cache. It doesn't matter which cgroups >> are or aren't active at this time or any other. We create copies per-cgroup, >> but we create it lazily, when someone will touch it. > > How do you detect that someone is touching it? kmem_alloc_cache will create mem_cgroup_get_kmem_cache. (protected by static_branches, so won't happen if you don't have at least non-root memcg using it) * Then it detects which memcg the calling process belongs to, * if it is the root memcg, go back to the allocation as quickly as we can * otherwise, in the creation process, you will notice that each cache has an index. memcg will store pointers to the copies and find them by the index. From this point on, all the code of the caches is reused (except for accounting the page)
creator: Glauber Costa
date: 2012-05-29T16:36:06-00:00

Re: [PATCH v3 12/28] slab: pass memcg parameter to kmem_cache_create
type: item
description: On Tue, 29 May 2012, Glauber Costa wrote: > > How do you detect that someone is touching it? > > kmem_alloc_cache will create mem_cgroup_get_kmem_cache. > (protected by static_branches, so won't happen if you don't have at least > non-root memcg using it) > > * Then it detects which memcg the calling process belongs to, > * if it is the root memcg, go back to the allocation as quickly as we > can > * otherwise, in the creation process, you will notice that each cache > has an index. memcg will store pointers to the copies and find them by > the index. > > From this point on, all the code of the caches is reused (except for > accounting the page) Well kmem_cache_alloc cache is the performance critical hotpath. If you are already there and doing all of that then would it not be better to simply count the objects allocated and freed per cgroup? Directly increment and decrement counters in a cgroup? You do not really need to duplicate the kmem_cache structure and do not need to modify allocators if you are willing to take that kind of a performance hit. Put a wrapper around kmem_cache_alloc/free and count things.
creator: Christoph Lameter
date: 2012-05-29T16:52:55-00:00

Re: [PATCH v3 12/28] slab: pass memcg parameter to kmem_cache_create
type: item
description: On 05/29/2012 08:52 PM, Christoph Lameter wrote: > Well kmem_cache_alloc cache is the performance critical hotpath. > > If you are already there and doing all of that then would it not be better > to simply count the objects allocated and freed per cgroup? Directly > increment and decrement counters in a cgroup? You do not really need to > duplicate the kmem_cache structure and do not need to modify allocators if > you are willing to take that kind of a performance hit. Put a wrapper > around kmem_cache_alloc/free and count things. Well, I see it as the difference between being a big slower, and a lot slower. Accounting in memcg is hard, specially because it is potentially hierarchical, (meaning you need to nest downwards until your parents). I never discussed that this is, unfortunately, a hotpath. However, I did try to minimize the impact as much as I could. Not to mention that the current scheme is bound to improvement as cgroups improve. One of the things being discussed is to having all cgroups always in the same hierarchy. If that ever happens, we can have the information about the current cgroup stored in a very accessible way, so to make this even faster. This felt like the best way I could do with the current infrastructure, (and again, I did make it free for people not limiting kmem), and is way, way cheaper than doing accounting here.
creator: Glauber Costa
date: 2012-05-29T16:59:54-00:00

Re: [PATCH v3 13/28] slub: create duplicate cache
type: item
description: On 05/29/2012 08:05 PM, Christoph Lameter wrote: > On Tue, 29 May 2012, Glauber Costa wrote: > >> Accounting pages seems just crazy to me. If new allocators come in the future, >> organizing the pages in a different way, instead of patching it here and >> there, we need to totally rewrite this. > > Quite to the contrary. We could either pass a THIS_IS_A_SLAB page flag to > the page allocator call or have a special call that does the accounting > and then calls the page allocator. The code could be completely in > cgroups. There would be no changes to the allocators aside from setting > the flag or calling the alternate page allocator functions. Again: for the page allocation itself, we could do it. (maybe we still can, keeping the rest of the approach, so as to simplify that particular piece of code, and reduce the churn inside the cache - I am all for it) But that only solves the page allocation part. I would still need to make sure the caller is directed to the right page. >>> Why do you need to increase the refcount? You made a full copy right? >> >> Yes, but I don't want this copy to go away while we have other caches around. > > You copied all metadata so what is there that you would still need should > the other copy go away? Well, consistency being one, because it sounded weird to have the parent cache being deleted while the kids are around. You wouldn't be able to reach them, for once. But one can argue that if you deleted the cache, why would you want to ever reach it? I can try to remove the refcount. > >> So, in the memcg internals, I used a different reference counter, to avoid >> messing with this one. I could use that, and leave the original refcnt alone. >> Would you prefer this? > > The refcounter is really not the issue. > > I am a bit worried about the various duplicate features here and there. > The approach is not tightened down yet. Well, I still think that duplication of the structure is better - a lot less intrusive - than messing with the ca…
creator: Glauber Costa
date: 2012-05-29T17:05:45-00:00

Re: [PATCH v3 13/28] slub: create duplicate cache
type: item
description: On Tue, 29 May 2012, Glauber Costa wrote: > I will try to at least have the page accounting done in a consistent way. How > about that? Ok. What do you mean by "consistent"? Since objects and pages can be used in a shared way and since accounting in many areas of the kernel is intentional fuzzy to avoid performance issues there is not that much of a requirement for accuracy. We have problems even just defining what the exact set of pages belonging to a task/process is.
creator: Christoph Lameter
date: 2012-05-29T17:25:12-00:00

Re: [PATCH v3 13/28] slub: create duplicate cache
type: item
description: On 05/29/2012 09:25 PM, Christoph Lameter wrote: >> I will try to at least have the page accounting done in a consistent way. How >> > about that? > Ok. What do you mean by "consistent"? Since objects and pages can be used > in a shared way and since accounting in many areas of the kernel is > intentional fuzzy to avoid performance issues there is not that much of a > requirement for accuracy. We have problems even just defining what the > exact set of pages belonging to a task/process is. > I mean consistent between allocators, done in a shared place. Note that what we do here *is* still fuzzy to some degree. We can have a level of sharing, and always account to the first one to touch, we don't go worrying about this because that would be hell. We also don't carry a process' objects around when we send it to a different cgroup. Those are all already simplications for performance and simplicity sake. But we really need a page to be filled with objects from the same cgroup, and the non-shared objects to be accounted to the right place. Otherwise, I don't think we can meet even the lighter of isolation guarantees.
creator: Glauber Costa
date: 2012-05-29T17:27:02-00:00

Re: [PATCH v3 13/28] slub: create duplicate cache
type: item
description: On Tue, 29 May 2012, Glauber Costa wrote: > But we really need a page to be filled with objects from the same cgroup, and > the non-shared objects to be accounted to the right place. No other subsystem has such a requirement. Even the NUMA nodes are mostly suggestions and can be ignored by the allocators to use memory from other pages. > Otherwise, I don't think we can meet even the lighter of isolation guarantees. The approach works just fine with NUMA and cpusets. Isolation is mostly done on the per node boundaries and you already have per node statistics.
creator: Christoph Lameter
date: 2012-05-29T19:26:02-00:00

Re: [PATCH v3 13/28] slub: create duplicate cache
type: item
description: On 05/29/2012 11:26 PM, Christoph Lameter wrote: > On Tue, 29 May 2012, Glauber Costa wrote: > >> But we really need a page to be filled with objects from the same cgroup, and >> the non-shared objects to be accounted to the right place. > > No other subsystem has such a requirement. Even the NUMA nodes are mostly > suggestions and can be ignored by the allocators to use memory from other > pages. Of course it does. Memcg itself has such a requirement. The collective set of processes needs to have the pages it uses accounted to it, and never go over limit. >> Otherwise, I don't think we can meet even the lighter of isolation guarantees. > > The approach works just fine with NUMA and cpusets. Isolation is mostly > done on the per node boundaries and you already have per node statistics. I don't know about cpusets in details, but at least with NUMA, this is not an apple-to-apple comparison. a NUMA node is not meant to contain you. A container is, and that is why it is called a container. NUMA just means what is the *best* node to put my memory. Now, if you actually say, through you syscalls "this is the node it should live in", then you have a constraint, that to the best of my knowledge is respected. Now isolation here, is done in the container boundary. (cgroups, to be generic).
creator: Glauber Costa
date: 2012-05-29T19:40:02-00:00

Re: [PATCH v3 13/28] slub: create duplicate cache
type: item
description: On Tue, 29 May 2012, Glauber Costa wrote: > I don't know about cpusets in details, but at least with NUMA, this is not an > apple-to-apple comparison. a NUMA node is not meant to contain you. A > container is, and that is why it is called a container. Cpusets contains sets of nodes. A cpusets "contains" nodes. These sets are associated with applications. > NUMA just means what is the *best* node to put my memory. > Now, if you actually say, through you syscalls "this is the node it should > live in", then you have a constraint, that to the best of my knowledge is > respected. Eith cpusets it means that memory needs to come from an assigned set of nodes. > Now isolation here, is done in the container boundary. (cgroups, to be > generic). Yes and with cpusets it is done at the cpuset boundary. Very much the same.
creator: Christoph Lameter
date: 2012-05-29T19:55:49-00:00

Re: [PATCH v3 13/28] slub: create duplicate cache
type: item
description: On 05/29/2012 11:55 PM, Christoph Lameter wrote: >> NUMA just means what is the*best* node to put my memory. >> > Now, if you actually say, through you syscalls "this is the node it should >> > live in", then you have a constraint, that to the best of my knowledge is >> > respected. > Eith cpusets it means that memory needs to come from an assigned set of > nodes. > >> > Now isolation here, is done in the container boundary. (cgroups, to be >> > generic). > Yes and with cpusets it is done at the cpuset boundary. Very much the > same. Well, I'd have to dive in the code a bit more, but that the impression that the documentation gives me, by saying: "Cpusets constrain the CPU and Memory placement of tasks to only the resources within a task's current cpuset." is that you can't allocate from a node outside that set. Is this correct? So extrapolating this to memcg, the situation is as follows: * You can't use more memory than what you are assigned to. * In order to do that, you need to account the memory you are using * and to account the memory you are using, all objects in the page must belong to you. Please note the following: Having two cgroups touching the same object is something. It tells something about the relationship between them. This is shared memory. Now having two cgroups putting objects in the same page, *does not mean _anything_*. It just mean that one had the luck to allocate just after the other. With a predictable enough workload, this is a recipe for working around the very protection we need to establish: one can DoS a physical box full of containers, by always allocating in someone else's pages, and pinning kernel memory down. Never releasing it, so the shrinkers are useless. So I still believe that if a page is allocated to a cgroup, all the objects in there belong to it - unless of course the sharing actually means something - and identifying this is just too complicated.
creator: Glauber Costa
date: 2012-05-29T20:08:38-00:00

Re: [PATCH v3 13/28] slub: create duplicate cache
type: item
description: On Wed, 30 May 2012, Glauber Costa wrote: > Well, I'd have to dive in the code a bit more, but that the impression that > the documentation gives me, by saying: > > "Cpusets constrain the CPU and Memory placement of tasks to only > the resources within a task's current cpuset." > > is that you can't allocate from a node outside that set. Is this correct? Basically yes but there are exceptions (like slab queues etc). Look at the hardwall stuff too that allows more exceptions for kernel allocations to use memory from other nodes. > So extrapolating this to memcg, the situation is as follows: > > * You can't use more memory than what you are assigned to. > * In order to do that, you need to account the memory you are using > * and to account the memory you are using, all objects in the page > must belong to you. Cpusets work at the page boundary and they do not have the requirement you are mentioning of all objects in the page having to belong to a certain cpusets. Let that go and things become much easier. > With a predictable enough workload, this is a recipe for working around the > very protection we need to establish: one can DoS a physical box full of > containers, by always allocating in someone else's pages, and pinning kernel > memory down. Never releasing it, so the shrinkers are useless. Sure you can construct hyperthetical cases like that. But then that is true already of other container like logic in the kernel already. > So I still believe that if a page is allocated to a cgroup, all the objects in > there belong to it - unless of course the sharing actually means something - > and identifying this is just too complicated. We have never worked container like logic like that in the kernel due to the complicated logic you would have to put in. The requirement that all objects in a page come from the same container is not necessary. If you drop this notion then things become very easy and the patches will become simple.
creator: Christoph Lameter
date: 2012-05-29T20:21:17-00:00

Re: [PATCH v3 13/28] slub: create duplicate cache
type: item
description: On 05/30/2012 12:21 AM, Christoph Lameter wrote: > On Wed, 30 May 2012, Glauber Costa wrote: > >> Well, I'd have to dive in the code a bit more, but that the impression that >> the documentation gives me, by saying: >> >> "Cpusets constrain the CPU and Memory placement of tasks to only >> the resources within a task's current cpuset." >> >> is that you can't allocate from a node outside that set. Is this correct? > > Basically yes but there are exceptions (like slab queues etc). Look at the > hardwall stuff too that allows more exceptions for kernel allocations to > use memory from other nodes. > >> So extrapolating this to memcg, the situation is as follows: >> >> * You can't use more memory than what you are assigned to. >> * In order to do that, you need to account the memory you are using >> * and to account the memory you are using, all objects in the page >> must belong to you. > > Cpusets work at the page boundary and they do not have the requirement you > are mentioning of all objects in the page having to belong to a certain > cpusets. Let that go and things become much easier. > >> With a predictable enough workload, this is a recipe for working around the >> very protection we need to establish: one can DoS a physical box full of >> containers, by always allocating in someone else's pages, and pinning kernel >> memory down. Never releasing it, so the shrinkers are useless. > > Sure you can construct hyperthetical cases like that. But then that is > true already of other container like logic in the kernel already. > >> So I still believe that if a page is allocated to a cgroup, all the objects in >> there belong to it - unless of course the sharing actually means something - >> and identifying this is just too complicated. > > We have never worked container like logic like that in the kernel due to > the complicated logic you would have to put in. The requirement that all > objects in a page come from the same container is not necessary. If you > drop this…
creator: Glauber Costa
date: 2012-05-29T20:25:36-00:00

Re: [PATCH v3 13/28] slub: create duplicate cache
type: item
description: Hi Christoph, On Tue, May 29, 2012 at 1:21 PM, Christoph Lameter <cl@linux.com> wrote: > On Wed, 30 May 2012, Glauber Costa wrote: > >> Well, I'd have to dive in the code a bit more, but that the impression that >> the documentation gives me, by saying: >> >> "Cpusets constrain the CPU and Memory placement of tasks to only >> the resources within a task's current cpuset." >> >> is that you can't allocate from a node outside that set. Is this correct? > > Basically yes but there are exceptions (like slab queues etc). Look at the > hardwall stuff too that allows more exceptions for kernel allocations to > use memory from other nodes. > >> So extrapolating this to memcg, the situation is as follows: >> >> * You can't use more memory than what you are assigned to. >> * In order to do that, you need to account the memory you are using >> * and to account the memory you are using, all objects in the page >> must belong to you. > > Cpusets work at the page boundary and they do not have the requirement you > are mentioning of all objects in the page having to belong to a certain > cpusets. Let that go and things become much easier. > >> With a predictable enough workload, this is a recipe for working around the >> very protection we need to establish: one can DoS a physical box full of >> containers, by always allocating in someone else's pages, and pinning kernel >> memory down. Never releasing it, so the shrinkers are useless. > > Sure you can construct hyperthetical cases like that. But then that is > true already of other container like logic in the kernel already. > >> So I still believe that if a page is allocated to a cgroup, all the objects in >> there belong to it - unless of course the sharing actually means something - >> and identifying this is just too complicated. > > We have never worked container like logic like that in the kernel due to > the complicated logic you would have to put in. The requirement that all > objects in a page come from the same containe…
creator: Suleiman Souhlal
date: 2012-05-29T20:57:41-00:00

Re: [PATCH v3 13/28] slub: create duplicate cache
type: item
description: Hello, Christoph, Glauber. On Wed, May 30, 2012 at 12:25:36AM +0400, Glauber Costa wrote: > >We have never worked container like logic like that in the kernel due to > >the complicated logic you would have to put in. The requirement that all > >objects in a page come from the same container is not necessary. If you > >drop this notion then things become very easy and the patches will become > >simple. > > I promise to look at that in more detail and get back to it. In the > meantime, I think it would be enlightening to hear from other > parties as well, specially the ones also directly interested in > using the technology. I don't think I'm too interested in using the technology ;) and haven't read the code (just glanced through the descriptions and discussions), but, in general, I think the approach of duplicating memory allocator per-memcg is a sane approach. It isn't the most efficient one with the possibility of wasting considerable amount of caching area per memcg but it is something which can mostly stay out of the way if done right and that's how I want cgroup implementations to be. The two goals for cgroup controllers that I think are important are proper (no, not crazy perfect but good enough) isolation and an implementation which doesn't impact !cg path in an intrusive manner - if someone who doesn't care about cgroup but knows and wants to work on the subsystem should be able to mostly ignore cgroup support. If that means overhead for cgroup users, so be it. Without looking at the actual code, my rainbow-farting unicorn here would be having a common slXb interface layer which handles interfacing with memory allocator users and cgroup and let slXb implement the same backend interface which doesn't care / know about cgroup at all (other than using the correct allocation context, that is). Glauber, would something like that be possible? Thanks. -- tejun
creator: Tejun Heo
date: 2012-05-30T01:29:55-00:00

Re: Re: [PATCH v3 13/28] slub: create duplicate cache
type: item
description: On Wed, 2012-05-30 at 10:29 +0900, Tejun Heo wrote: > Hello, Christoph, Glauber. > > On Wed, May 30, 2012 at 12:25:36AM +0400, Glauber Costa wrote: > > >We have never worked container like logic like that in the kernel due to > > >the complicated logic you would have to put in. The requirement that all > > >objects in a page come from the same container is not necessary. If you > > >drop this notion then things become very easy and the patches will become > > >simple. > > > > I promise to look at that in more detail and get back to it. In the > > meantime, I think it would be enlightening to hear from other > > parties as well, specially the ones also directly interested in > > using the technology. > > I don't think I'm too interested in using the technology ;) and > haven't read the code (just glanced through the descriptions and > discussions), but, in general, I think the approach of duplicating > memory allocator per-memcg is a sane approach. It isn't the most > efficient one with the possibility of wasting considerable amount of > caching area per memcg but it is something which can mostly stay out > of the way if done right and that's how I want cgroup implementations > to be. Exactly: we at parallels initially disliked the cgroup multipled by slab approach (Our beancounters do count objects) because we feared memory wastage and density is very important to us (which tends to mean efficient use of memory) however, when we ran through the calculations in Prague, you can show that we have ~200 slabs and if each wastes half a page, thats ~4MB memory lost per container. Since most virtual environments are of the order nowadays of 0.5GB, we feel it's an annoying but acceptable price to pay. James > The two goals for cgroup controllers that I think are important are > proper (no, not crazy perfect but good enough) isolation and an > implementation which doesn't impact !cg path in an intrusive manner - > if someone who doesn't care about cgroup but knows and wants t…
creator: James Bottomley
date: 2012-05-30T07:28:26-00:00

Re: [PATCH v3 13/28] slub: create duplicate cache
type: item
description: On 05/30/2012 05:29 AM, Tejun Heo wrote: > The two goals for cgroup controllers that I think are important are > proper (no, not crazy perfect but good enough) isolation and an > implementation which doesn't impact !cg path in an intrusive manner - > if someone who doesn't care about cgroup but knows and wants to work > on the subsystem should be able to mostly ignore cgroup support. If > that means overhead for cgroup users, so be it. Well, my code in the slab is totally wrapped in static branches. They only come active when the first group is *limited* (not even created: you can have a thousand memcg, if none of them are kmem limited, nothing will happen). After that, the cost paid is to find out at which cgroup the process is at. I believe that if we had a faster way for this (like for instance: if we had a single hierarchy, the scheduler could put this in a percpu variable after context switch - or any other method), then the cost of it could be really low, even when this is enabled. > Without looking at the actual code, my rainbow-farting unicorn here > would be having a common slXb interface layer which handles > interfacing with memory allocator users and cgroup and let slXb > implement the same backend interface which doesn't care / know about > cgroup at all (other than using the correct allocation context, that > is). Glauber, would something like that be possible? It is a matter of degree. There *is* a lot of stuff in common code, and I tried to do it as much as I could. Christoph gave me a nice idea about hinting to the page allocator that this page is a slab page before the allocation, and then we could account from the page allocator directly - without touching the cache code at all. This could be done, but some stuff would still be there, basically because of differences in how the allocator behaves. I think long term Christoph's effort to produce common code among them will help a lot, if they stabilize their behavior in certain areas. I will rework …
creator: Glauber Costa
date: 2012-05-30T07:54:16-00:00

Re: [PATCH v3 13/28] slub: create duplicate cache
type: item
description: Hello, Glauber. On Wed, May 30, 2012 at 4:54 PM, Glauber Costa <glommer@parallels.com> wrote: > On 05/30/2012 05:29 AM, Tejun Heo wrote: >> >> The two goals for cgroup controllers that I think are important are >> proper (no, not crazy perfect but good enough) isolation and an >> implementation which doesn't impact !cg path in an intrusive manner - >> if someone who doesn't care about cgroup but knows and wants to work >> on the subsystem should be able to mostly ignore cgroup support. If >> that means overhead for cgroup users, so be it. > > > Well, my code in the slab is totally wrapped in static branches. They only > come active when the first group is *limited* (not even created: you can > have a thousand memcg, if none of them are kmem limited, nothing will > happen). Great, but I'm not sure why you're trying to emphasize that while my point was about memory overhead and that it's OK to have some overheads for cg users. :) > After that, the cost paid is to find out at which cgroup the process is at. > I believe that if we had a faster way for this (like for instance: if we had > a single hierarchy, the scheduler could put this in a percpu variable after > context switch - or any other method), then the cost of it could be really > low, even when this is enabled. Someday, hopefully. > I will rework this series to try work more towards this goal, but at least > for now I'll keep duplicating the caches. I still don't believe that a loose > accounting to the extent Christoph proposed will achieve what we need this > to achieve. Yeah, I prefer your per-cg cache approach but do hope that it stays as far from actual allocator code as possible. Christoph, would it be acceptable if the cg logic is better separated? Thanks. -- tejun
creator: Tejun Heo
date: 2012-05-30T08:02:35-00:00

Re: [PATCH v3 12/28] slab: pass memcg parameter to kmem_cache_create
type: item
description: On Tue, May 29, 2012 at 11:52:55AM -0500, Christoph Lameter wrote: > On Tue, 29 May 2012, Glauber Costa wrote: > > > > How do you detect that someone is touching it? > > > > kmem_alloc_cache will create mem_cgroup_get_kmem_cache. > > (protected by static_branches, so won't happen if you don't have at least > > non-root memcg using it) > > > > * Then it detects which memcg the calling process belongs to, > > * if it is the root memcg, go back to the allocation as quickly as we > > can > > * otherwise, in the creation process, you will notice that each cache > > has an index. memcg will store pointers to the copies and find them by > > the index. > > > > From this point on, all the code of the caches is reused (except for > > accounting the page) > > Well kmem_cache_alloc cache is the performance critical hotpath. > > If you are already there and doing all of that then would it not be better > to simply count the objects allocated and freed per cgroup? Directly > increment and decrement counters in a cgroup? You do not really need to > duplicate the kmem_cache structure and do not need to modify allocators if > you are willing to take that kind of a performance hit. Put a wrapper > around kmem_cache_alloc/free and count things. I believe one of the issues is also that a task can migrate to another cgroup anytime. But an object that has been charged to a cgroup must be later uncharged to the same, unless you move the charge as you move the task. But then it means you need to keep track of the allocations per task, and you also need to be able to do that reverse mapping (object -> allocating task) because your object can be allocated by task A but later freed by task B. Then when you do the uncharge it must happen to the cgroup of A, not the one of B. That all would be much more complicated and performance sensitive than what this patchset does. Dealing with duplicate caches for accounting seem to me a good tradeoff between allocation performance hot path and maintainin…
creator: Frederic Weisbecker
date: 2012-05-30T11:01:37-00:00

Re: [PATCH v3 16/28] memcg: kmem controller charge/uncharge infrastructure
type: item
description: On Fri, May 25, 2012 at 05:03:36PM +0400, Glauber Costa wrote: > #endif /* CONFIG_CGROUP_MEM_RES_CTLR_KMEM */ > +static __always_inline struct kmem_cache * > +mem_cgroup_get_kmem_cache(struct kmem_cache *cachep, gfp_t gfp) > +{ > + if (!mem_cgroup_kmem_on) > + return cachep; > + if (!current->mm) > + return cachep; > + if (in_interrupt()) > + return cachep; Does that mean interrupts are kept out of accounting?
creator: Frederic Weisbecker
date: 2012-05-30T12:17:09-00:00

Re: [PATCH v3 16/28] memcg: kmem controller charge/uncharge infrastructure
type: item
description: On 05/30/2012 04:17 PM, Frederic Weisbecker wrote: > On Fri, May 25, 2012 at 05:03:36PM +0400, Glauber Costa wrote: >> #endif /* CONFIG_CGROUP_MEM_RES_CTLR_KMEM */ >> +static __always_inline struct kmem_cache * >> +mem_cgroup_get_kmem_cache(struct kmem_cache *cachep, gfp_t gfp) >> +{ >> + if (!mem_cgroup_kmem_on) >> + return cachep; >> + if (!current->mm) >> + return cachep; >> + if (in_interrupt()) >> + return cachep; > > Does that mean interrupts are kept out of accounting? Well, since interrupts have no process context, if you are in an interrupt I can't think of any sane thing to do than relay it to the root memcg. That's what happen when I return cachep: I return the original parent cache, and we allocate from that.
creator: Glauber Costa
date: 2012-05-30T12:26:28-00:00

Re: [PATCH v3 16/28] memcg: kmem controller charge/uncharge infrastructure
type: item
description: On Fri, May 25, 2012 at 05:03:36PM +0400, Glauber Costa wrote: > +bool __mem_cgroup_new_kmem_page(struct page *page, gfp_t gfp) > +{ > + struct mem_cgroup *memcg; > + struct page_cgroup *pc; > + bool ret = true; > + size_t size; > + struct task_struct *p; > + > + if (!current->mm || in_interrupt()) > + return true; > + > + rcu_read_lock(); > + p = rcu_dereference(current->mm->owner); > + memcg = mem_cgroup_from_task(p); So this takes the memcg of the group owner rather than the task? I understand why we want this for user memory, but for kernel?
creator: Frederic Weisbecker
date: 2012-05-30T12:34:08-00:00

Re: [PATCH v3 16/28] memcg: kmem controller charge/uncharge infrastructure
type: item
description: On 05/30/2012 04:34 PM, Frederic Weisbecker wrote: > On Fri, May 25, 2012 at 05:03:36PM +0400, Glauber Costa wrote: >> +bool __mem_cgroup_new_kmem_page(struct page *page, gfp_t gfp) >> +{ >> + struct mem_cgroup *memcg; >> + struct page_cgroup *pc; >> + bool ret = true; >> + size_t size; >> + struct task_struct *p; >> + >> + if (!current->mm || in_interrupt()) >> + return true; >> + >> + rcu_read_lock(); >> + p = rcu_dereference(current->mm->owner); >> + memcg = mem_cgroup_from_task(p); > > So this takes the memcg of the group owner rather than the > task? I understand why we want this for user memory, but for > kernel? That was already discussed when this first came up in my last submission If I recall correctly, Kame pointed out that this would be needed for proper OOM-scoring and killing. Now of course we won't oom kernel threads or anything like that. But since this is also accounted towards memcg, it should at least be consistent with each memcg it accounts to. We can't account kmem for the thread's memcg, and mem to the process'.
creator: Glauber Costa
date: 2012-05-30T12:38:39-00:00

Re: [PATCH v3 16/28] memcg: kmem controller charge/uncharge infrastructure
type: item
description: On Fri, May 25, 2012 at 05:03:36PM +0400, Glauber Costa wrote: > +struct kmem_cache *__mem_cgroup_get_kmem_cache(struct kmem_cache *cachep, > + gfp_t gfp) > +{ > + struct mem_cgroup *memcg; > + int idx; > + struct task_struct *p; > + > + gfp |= cachep->allocflags; > + > + if (cachep->memcg_params.memcg) > + return cachep; > + > + idx = cachep->memcg_params.id; > + VM_BUG_ON(idx == -1); > + > + p = rcu_dereference(current->mm->owner); > + memcg = mem_cgroup_from_task(p); > + > + if (!mem_cgroup_kmem_enabled(memcg)) > + return cachep; > + > + if (memcg->slabs[idx] == NULL) { > + memcg_create_cache_enqueue(memcg, cachep); > + return cachep; > + } > + > + return memcg->slabs[idx]; > +} > +EXPORT_SYMBOL(__mem_cgroup_get_kmem_cache); > + > +bool __mem_cgroup_new_kmem_page(struct page *page, gfp_t gfp) > +{ > + struct mem_cgroup *memcg; > + struct page_cgroup *pc; > + bool ret = true; > + size_t size; > + struct task_struct *p; > + > + if (!current->mm || in_interrupt()) > + return true; > + > + rcu_read_lock(); > + p = rcu_dereference(current->mm->owner); > + memcg = mem_cgroup_from_task(p); > + > + if (!mem_cgroup_kmem_enabled(memcg)) > + goto out; Do you think it's possible that this memcg can be destroyed (like ss->destroy()) concurrently? Probably not because there is a synchronize_rcu() in cgroup_diput() so as long as we are in rcu_read_lock() we are fine. OTOH current->mm->owner can exit() right after we fetched its memcg and thus the css_set can be freed concurrently? And then the cgroup itself after we call rcu_read_unlock() due to cgroup_diput(). And yet we are doing the mem_cgroup_get() below unconditionally assuming it's always fine to get a reference to it. May be I'm missing something? > + mem_cgroup_get(memcg); > + > + size = (1 << compound_order(page)) << PAGE_SHIFT; > + > + ret = memcg_charge_kmem(memcg, gfp, size) == 0; > + if (!ret) { > + mem_cgroup_put(memcg); > + goto out; > + } > + > + pc = lookup_page_cgroup(page); > + lock_page_cgroup(pc); > + pc->m…
creator: Frederic Weisbecker
date: 2012-05-30T13:04:18-00:00

Re: [PATCH v3 16/28] memcg: kmem controller charge/uncharge infrastructure
type: item
description: On 05/30/2012 05:04 PM, Frederic Weisbecker wrote: > Do you think it's possible that this memcg can be destroyed (like ss->destroy()) > concurrently? > > Probably not because there is a synchronize_rcu() in cgroup_diput() so as long > as we are in rcu_read_lock() we are fine. > > OTOH current->mm->owner can exit() right after we fetched its memcg and thus the css_set > can be freed concurrently? And then the cgroup itself after we call rcu_read_unlock() > due to cgroup_diput(). > And yet we are doing the mem_cgroup_get() below unconditionally assuming it's > always fine to get a reference to it. > > May be I'm missing something? When a cache is created, we grab a reference to the memcg. So after the cache is created, no. When destroy is called, we flush the create queue, so if the cache is not created yet, it will just disappear. I think the only problem that might happen is in the following scenario: * cache gets created, but ref count is not yet taken * memcg disappears * we try to inc refcount for a non-existent memcg, and crash. This would be trivially solvable by grabing the reference earlier. But even then, I need to audit this further to make sure it is really an issue.
creator: Glauber Costa
date: 2012-05-30T13:06:22-00:00

Re: [PATCH v3 16/28] memcg: kmem controller charge/uncharge infrastructure
type: item
description: On 05/30/2012 05:11 PM, Frederic Weisbecker wrote: > Can we have at least a comment in the code that explain the reasons of taking the > owner rather than the task? It's not going to be very obvious to future reviewers. Yes.
creator: Glauber Costa
date: 2012-05-30T13:09:52-00:00

Re: [PATCH v3 16/28] memcg: kmem controller charge/uncharge infrastructure
type: item
description: On Wed, May 30, 2012 at 04:38:39PM +0400, Glauber Costa wrote: > On 05/30/2012 04:34 PM, Frederic Weisbecker wrote: > >On Fri, May 25, 2012 at 05:03:36PM +0400, Glauber Costa wrote: > >>+bool __mem_cgroup_new_kmem_page(struct page *page, gfp_t gfp) > >>+{ > >>+ struct mem_cgroup *memcg; > >>+ struct page_cgroup *pc; > >>+ bool ret = true; > >>+ size_t size; > >>+ struct task_struct *p; > >>+ > >>+ if (!current->mm || in_interrupt()) > >>+ return true; > >>+ > >>+ rcu_read_lock(); > >>+ p = rcu_dereference(current->mm->owner); > >>+ memcg = mem_cgroup_from_task(p); > > > >So this takes the memcg of the group owner rather than the > >task? I understand why we want this for user memory, but for > >kernel? > > That was already discussed when this first came up in my last submission > If I recall correctly, Kame pointed out that this would be needed > for proper OOM-scoring and killing. Can we have at least a comment in the code that explain the reasons of taking the owner rather than the task? It's not going to be very obvious to future reviewers. > Now of course we won't oom kernel threads or anything like that. Seems we are not even accounting them anyway. > But since this is also accounted towards memcg, it should at least be > consistent with each memcg it accounts to. > > We can't account kmem for the thread's memcg, and mem to the process'. Don't know. This goes a bit against cgroups semantics which group at the task level and not process. But I personally don't mind much, as long as it's documented.
creator: Frederic Weisbecker
date: 2012-05-30T13:11:01-00:00

Re: [PATCH v3 16/28] memcg: kmem controller charge/uncharge infrastructure
type: item
description: On Wed, May 30, 2012 at 05:06:22PM +0400, Glauber Costa wrote: > On 05/30/2012 05:04 PM, Frederic Weisbecker wrote: > >Do you think it's possible that this memcg can be destroyed (like ss->destroy()) > >concurrently? > > > >Probably not because there is a synchronize_rcu() in cgroup_diput() so as long > >as we are in rcu_read_lock() we are fine. > > > >OTOH current->mm->owner can exit() right after we fetched its memcg and thus the css_set > >can be freed concurrently? And then the cgroup itself after we call rcu_read_unlock() > >due to cgroup_diput(). > >And yet we are doing the mem_cgroup_get() below unconditionally assuming it's > >always fine to get a reference to it. > > > >May be I'm missing something? > When a cache is created, we grab a reference to the memcg. So after > the cache is created, no. > > When destroy is called, we flush the create queue, so if the cache > is not created yet, it will just disappear. > > I think the only problem that might happen is in the following scenario: > > * cache gets created, but ref count is not yet taken > * memcg disappears > * we try to inc refcount for a non-existent memcg, and crash. > > This would be trivially solvable by grabing the reference earlier. > But even then, I need to audit this further to make sure it is > really an issue. Right. __mem_cgroup_get_kmem_cache() fetches the memcg of the owner and calls memcg_create_cache_enqueue() which does css_tryget(&memcg->css). After this tryget I think you're fine. And in-between you're safe against css_set removal due to rcu_read_lock(). I'm less clear with __mem_cgroup_new_kmem_page() though...
creator: Frederic Weisbecker
date: 2012-05-30T13:37:39-00:00

Re: [PATCH v3 16/28] memcg: kmem controller charge/uncharge infrastructure
type: item
description: On 05/30/2012 05:37 PM, Frederic Weisbecker wrote: > Right. __mem_cgroup_get_kmem_cache() fetches the memcg of the owner > and calls memcg_create_cache_enqueue() which does css_tryget(&memcg->css). > After this tryget I think you're fine. And in-between you're safe against > css_set removal due to rcu_read_lock(). > > I'm less clear with __mem_cgroup_new_kmem_page() though... That one does not get memcg->css but it does call mem_cgroup_get(), that does prevent against the memcg structure being freed, which I believe to be good enough.
creator: Glauber Costa
date: 2012-05-30T13:37:57-00:00

Re: [PATCH v3 16/28] memcg: kmem controller charge/uncharge infrastructure
type: item
description: On Wed, May 30, 2012 at 05:37:57PM +0400, Glauber Costa wrote: > On 05/30/2012 05:37 PM, Frederic Weisbecker wrote: > >Right. __mem_cgroup_get_kmem_cache() fetches the memcg of the owner > >and calls memcg_create_cache_enqueue() which does css_tryget(&memcg->css). > >After this tryget I think you're fine. And in-between you're safe against > >css_set removal due to rcu_read_lock(). > > > >I'm less clear with __mem_cgroup_new_kmem_page() though... > > That one does not get memcg->css but it does call mem_cgroup_get(), > that does prevent against the memcg structure being freed, which I > believe to be good enough. What if the owner calls cgroup_exit() between mem_cgroup_from_task() and mem_cgroup_get()? The css_set which contains the memcg gets freed. Also the reference on the memcg doesn't even prevent the css_set to be removed, does it?
creator: Frederic Weisbecker
date: 2012-05-30T13:53:21-00:00

Re: [PATCH v3 16/28] memcg: kmem controller charge/uncharge infrastructure
type: item
description: On 05/30/2012 05:53 PM, Frederic Weisbecker wrote: > On Wed, May 30, 2012 at 05:37:57PM +0400, Glauber Costa wrote: >> On 05/30/2012 05:37 PM, Frederic Weisbecker wrote: >>> Right. __mem_cgroup_get_kmem_cache() fetches the memcg of the owner >>> and calls memcg_create_cache_enqueue() which does css_tryget(&memcg->css). >>> After this tryget I think you're fine. And in-between you're safe against >>> css_set removal due to rcu_read_lock(). >>> >>> I'm less clear with __mem_cgroup_new_kmem_page() though... >> >> That one does not get memcg->css but it does call mem_cgroup_get(), >> that does prevent against the memcg structure being freed, which I >> believe to be good enough. > > What if the owner calls cgroup_exit() between mem_cgroup_from_task() > and mem_cgroup_get()? The css_set which contains the memcg gets freed. > Also the reference on the memcg doesn't even prevent the css_set to > be removed, does it? It doesn't, but we don't really care. The css can go away, if the memcg structure stays. The caches will outlive the memcg anyway, since it is possible that you delete it, with some caches still holding objects that are not freed (they will be marked as dead).
creator: Glauber Costa
date: 2012-05-30T13:55:38-00:00

Re: [PATCH v3 16/28] memcg: kmem controller charge/uncharge infrastructure
type: item
description: On Wed, May 30, 2012 at 05:55:38PM +0400, Glauber Costa wrote: > On 05/30/2012 05:53 PM, Frederic Weisbecker wrote: > >On Wed, May 30, 2012 at 05:37:57PM +0400, Glauber Costa wrote: > >>On 05/30/2012 05:37 PM, Frederic Weisbecker wrote: > >>>Right. __mem_cgroup_get_kmem_cache() fetches the memcg of the owner > >>>and calls memcg_create_cache_enqueue() which does css_tryget(&memcg->css). > >>>After this tryget I think you're fine. And in-between you're safe against > >>>css_set removal due to rcu_read_lock(). > >>> > >>>I'm less clear with __mem_cgroup_new_kmem_page() though... > >> > >>That one does not get memcg->css but it does call mem_cgroup_get(), > >>that does prevent against the memcg structure being freed, which I > >>believe to be good enough. > > > >What if the owner calls cgroup_exit() between mem_cgroup_from_task() > >and mem_cgroup_get()? The css_set which contains the memcg gets freed. > >Also the reference on the memcg doesn't even prevent the css_set to > >be removed, does it? > It doesn't, but we don't really care. The css can go away, if the > memcg structure stays. Ah right, the memcg itself is only freed at destroy time. > The caches will outlive the memcg anyway, > since it is possible that you delete it, with some caches still > holding objects that > are not freed (they will be marked as dead). I guess I need to look at how the destroy path is handled in your patchset then. Or how you ensure that __mem_cgroup_new_kmem_page() can't race against destroy.
creator: Frederic Weisbecker
date: 2012-05-30T15:33:00-00:00

Re: [PATCH v3 13/28] slub: create duplicate cache
type: item
description: On Wed, 30 May 2012, Tejun Heo wrote: > Yeah, I prefer your per-cg cache approach but do hope that it stays as > far from actual allocator code as possible. Christoph, would it be > acceptable if the cg logic is better separated? Certainly anything that would allow this to be separated out would be appreciated. I do not anticipate to ever run cgroup in my environment and that is due to the additional latency created in key OS paths. Memory we have enough. The increased cache footprint is killing performance.
creator: Christoph Lameter
date: 2012-05-30T15:37:49-00:00

Re: [PATCH v3 16/28] memcg: kmem controller charge/uncharge infrastructure
type: item
description: On 05/30/2012 07:33 PM, Frederic Weisbecker wrote: > On Wed, May 30, 2012 at 05:55:38PM +0400, Glauber Costa wrote: >> On 05/30/2012 05:53 PM, Frederic Weisbecker wrote: >>> On Wed, May 30, 2012 at 05:37:57PM +0400, Glauber Costa wrote: >>>> On 05/30/2012 05:37 PM, Frederic Weisbecker wrote: >>>>> Right. __mem_cgroup_get_kmem_cache() fetches the memcg of the owner >>>>> and calls memcg_create_cache_enqueue() which does css_tryget(&memcg->css). >>>>> After this tryget I think you're fine. And in-between you're safe against >>>>> css_set removal due to rcu_read_lock(). >>>>> >>>>> I'm less clear with __mem_cgroup_new_kmem_page() though... >>>> >>>> That one does not get memcg->css but it does call mem_cgroup_get(), >>>> that does prevent against the memcg structure being freed, which I >>>> believe to be good enough. >>> >>> What if the owner calls cgroup_exit() between mem_cgroup_from_task() >>> and mem_cgroup_get()? The css_set which contains the memcg gets freed. >>> Also the reference on the memcg doesn't even prevent the css_set to >>> be removed, does it? >> It doesn't, but we don't really care. The css can go away, if the >> memcg structure stays. > > Ah right, the memcg itself is only freed at destroy time. > >> The caches will outlive the memcg anyway, >> since it is possible that you delete it, with some caches still >> holding objects that >> are not freed (they will be marked as dead). > > I guess I need to look at how the destroy path is handled in your patchset > then. Or how you ensure that __mem_cgroup_new_kmem_page() can't race against > destroy. Appreciate that, thanks.
creator: Glauber Costa
date: 2012-05-30T16:16:59-00:00

Re: [PATCH v3 00/28] kmem limitation for memcg
type: item
description: On Fri, May 25, 2012 at 05:03:20PM +0400, Glauber Costa wrote: > Hello All, > > This is my new take for the memcg kmem accounting. This should merge > all of the previous comments from you, plus fix a bunch of bugs. > > At this point, I consider the series pretty mature. Since last submission > 2 weeks ago, I focused on broadening the testing coverage. Some bugs were > fixed, but that of course doesn't mean no bugs exist. > > I believe some of the early patches here are already in some trees around. > I don't know who should pick this, so if everyone agrees with what's in here, > please just ack them and tell me which tree I should aim for (-mm? Hocko's?) > and I'll rebase it. > > I should point out again that most, if not all, of the code in the caches > are wrapped in static_key areas, meaning they will be completely patched out > until the first limit is set. Enabling and disabling of static_keys incorporate > the last fixes for sock memcg, and should be pretty robust. > > I also put a lot of effort, as you will all see, in the proper separation > of the patches, so the review process is made as easy as the complexity of > the work allows to. So I believe that if I want to implement a per kernel stack accounting/limitation, I need to work on top of your patchset. What do you think about having some sub kmem accounting based on the caches? For example there could be a specific accounting per kmem cache. Like if we use a specific kmem cache to allocate the kernel stack (as is done by some archs but I can generalize that for those who want kernel stack accounting), allocations are accounted globally in the memcg as done in your patchset but also on a seperate counter only for this kmem cache on the memcg, resulting in a kmem.stack.usage somewhere. The concept of per kmem cache accounting can be expanded more for any kind of finegrained kmem accounting. Thoughts?
creator: Frederic Weisbecker
date: 2012-06-07T10:26:10-00:00

Re: [PATCH v3 00/28] kmem limitation for memcg
type: item
description: On 06/07/2012 02:26 PM, Frederic Weisbecker wrote: > On Fri, May 25, 2012 at 05:03:20PM +0400, Glauber Costa wrote: >> Hello All, >> >> This is my new take for the memcg kmem accounting. This should merge >> all of the previous comments from you, plus fix a bunch of bugs. >> >> At this point, I consider the series pretty mature. Since last submission >> 2 weeks ago, I focused on broadening the testing coverage. Some bugs were >> fixed, but that of course doesn't mean no bugs exist. >> >> I believe some of the early patches here are already in some trees around. >> I don't know who should pick this, so if everyone agrees with what's in here, >> please just ack them and tell me which tree I should aim for (-mm? Hocko's?) >> and I'll rebase it. >> >> I should point out again that most, if not all, of the code in the caches >> are wrapped in static_key areas, meaning they will be completely patched out >> until the first limit is set. Enabling and disabling of static_keys incorporate >> the last fixes for sock memcg, and should be pretty robust. >> >> I also put a lot of effort, as you will all see, in the proper separation >> of the patches, so the review process is made as easy as the complexity of >> the work allows to. > > So I believe that if I want to implement a per kernel stack accounting/limitation, > I need to work on top of your patchset. > > What do you think about having some sub kmem accounting based on the caches? > For example there could be a specific accounting per kmem cache. > > Like if we use a specific kmem cache to allocate the kernel stack > (as is done by some archs but I can generalize that for those who want > kernel stack accounting), allocations are accounted globally in the memcg as > done in your patchset but also on a seperate counter only for this kmem cache > on the memcg, resulting in a kmem.stack.usage somewhere. > > The concept of per kmem cache accounting can be expanded more for any > kind of finegrained kmem accounting. > > Though…
creator: Glauber Costa
date: 2012-06-07T10:53:07-00:00

Re: [PATCH v3 00/28] kmem limitation for memcg
type: item
description: On Thu, Jun 07, 2012 at 02:53:07PM +0400, Glauber Costa wrote: > On 06/07/2012 02:26 PM, Frederic Weisbecker wrote: > >On Fri, May 25, 2012 at 05:03:20PM +0400, Glauber Costa wrote: > >>Hello All, > >> > >>This is my new take for the memcg kmem accounting. This should merge > >>all of the previous comments from you, plus fix a bunch of bugs. > >> > >>At this point, I consider the series pretty mature. Since last submission > >>2 weeks ago, I focused on broadening the testing coverage. Some bugs were > >>fixed, but that of course doesn't mean no bugs exist. > >> > >>I believe some of the early patches here are already in some trees around. > >>I don't know who should pick this, so if everyone agrees with what's in here, > >>please just ack them and tell me which tree I should aim for (-mm? Hocko's?) > >>and I'll rebase it. > >> > >>I should point out again that most, if not all, of the code in the caches > >>are wrapped in static_key areas, meaning they will be completely patched out > >>until the first limit is set. Enabling and disabling of static_keys incorporate > >>the last fixes for sock memcg, and should be pretty robust. > >> > >>I also put a lot of effort, as you will all see, in the proper separation > >>of the patches, so the review process is made as easy as the complexity of > >>the work allows to. > > > >So I believe that if I want to implement a per kernel stack accounting/limitation, > >I need to work on top of your patchset. > > > >What do you think about having some sub kmem accounting based on the caches? > >For example there could be a specific accounting per kmem cache. > > > >Like if we use a specific kmem cache to allocate the kernel stack > >(as is done by some archs but I can generalize that for those who want > >kernel stack accounting), allocations are accounted globally in the memcg as > >done in your patchset but also on a seperate counter only for this kmem cache > >on the memcg, resulting in a kmem.stack.usage somewhere. > > > >The conc…
creator: Frederic Weisbecker
date: 2012-06-07T14:00:45-00:00

Re: [PATCH v3 00/28] kmem limitation for memcg
type: item
description: (2012/06/07 23:00), Frederic Weisbecker wrote: > On Thu, Jun 07, 2012 at 02:53:07PM +0400, Glauber Costa wrote: >> On 06/07/2012 02:26 PM, Frederic Weisbecker wrote: >>> On Fri, May 25, 2012 at 05:03:20PM +0400, Glauber Costa wrote: >>>> Hello All, >>>> >>>> This is my new take for the memcg kmem accounting. This should merge >>>> all of the previous comments from you, plus fix a bunch of bugs. >>>> >>>> At this point, I consider the series pretty mature. Since last submission >>>> 2 weeks ago, I focused on broadening the testing coverage. Some bugs were >>>> fixed, but that of course doesn't mean no bugs exist. >>>> >>>> I believe some of the early patches here are already in some trees around. >>>> I don't know who should pick this, so if everyone agrees with what's in here, >>>> please just ack them and tell me which tree I should aim for (-mm? Hocko's?) >>>> and I'll rebase it. >>>> >>>> I should point out again that most, if not all, of the code in the caches >>>> are wrapped in static_key areas, meaning they will be completely patched out >>>> until the first limit is set. Enabling and disabling of static_keys incorporate >>>> the last fixes for sock memcg, and should be pretty robust. >>>> >>>> I also put a lot of effort, as you will all see, in the proper separation >>>> of the patches, so the review process is made as easy as the complexity of >>>> the work allows to. >>> >>> So I believe that if I want to implement a per kernel stack accounting/limitation, >>> I need to work on top of your patchset. >>> >>> What do you think about having some sub kmem accounting based on the caches? >>> For example there could be a specific accounting per kmem cache. >>> >>> Like if we use a specific kmem cache to allocate the kernel stack >>> (as is done by some archs but I can generalize that for those who want >>> kernel stack accounting), allocations are accounted globally in the memcg as >>> done in your patchset but also on a seperate counter only for this kmem cache…
creator: KAMEZAWA Hiroyuki
date: 2012-06-14T02:24:53-00:00