OpenVZ Forum - RDF feed
type: channel
items: [PATCH v2 00/29] kmem limitation for memcg
items: [PATCH v2 01/29] slab: dup name string
items: [PATCH v2 02/29] slub: fix slab_state for slub
items: [PATCH v2 03/29] memcg: Always free struct memcg through schedule_work()
items: [PATCH v2 04/29] slub: always get the cache from its page in kfree
items: [PATCH v2 05/29] slab: rename gfpflags to allocflags
items: [PATCH v2 06/29] memcg: Make it possible to use the stock for more than one page.
items: [PATCH v2 07/29] memcg: Reclaim when more than one page needed.
items: [PATCH v2 08/29] slab: use obj_size field of struct kmem_cache when not debugging
items: [PATCH v2 09/29] memcg: change defines to an enum
items: [PATCH v2 10/29] res_counter: don't force return value checking in res_counter_charge_nofail
items: [PATCH v2 11/29] cgroups: ability to stop res charge propagation on bounded ancestor
items: [PATCH v2 12/29] kmem slab accounting basic infrastructure
items: [PATCH v2 13/29] slab/slub: struct memcg_params
items: [PATCH v2 14/29] slub: consider a memcg parameter in kmem_create_cache
items: [PATCH v2 15/29] slab: pass memcg parameter to kmem_cache_create
items: [PATCH v2 16/29] slub: create duplicate cache
items: [PATCH v2 17/29] slab: create duplicate cache
items: [PATCH v2 18/29] memcg: kmem controller charge/uncharge infrastructure
items: [PATCH v2 19/29] skip memcg kmem allocations in specified code regions
items: [PATCH v2 20/29] slub: charge allocation to a memcg
items: [PATCH v2 21/29] slab: per-memcg accounting of slab caches
items: [PATCH v2 22/29] memcg: disable kmem code when not in use.
items: [PATCH v2 23/29] memcg: destroy memcg caches
items: [PATCH v2 24/29] memcg/slub: shrink dead caches
items: [PATCH v2 25/29] memcg: Track all the memcg children of a kmem_cache.
items: [PATCH v2 26/29] memcg: Per-memcg memory.kmem.slabinfo file.
items: [PATCH v2 27/29] slub: create slabinfo file for memcg
items: [PATCH v2 28/29] slub: track all children of a kmem cache
items: [PATCH v2 29/29] Documentation: add documentation for slab tracker for memcg
items: Re: [PATCH v2 02/29] slub: fix slab_state for slub
items: Re: [PATCH v2 04/29] slub: always get the cache from its page in kfree
items: Re: [PATCH v2 05/29] slab: rename gfpflags to allocflags
items: Re: [PATCH v2 00/29] kmem limitation for memcg
items: Re: [PATCH v2 19/29] skip memcg kmem allocations in specified code regions
items: Re: [PATCH v2 18/29] memcg: kmem controller charge/uncharge infrastructure
items: Re: [PATCH v2 11/29] cgroups: ability to stop res charge propagation on bounded ancestor
items: Re: [PATCH v2 01/29] slab: dup name string

[PATCH v2 00/29] kmem limitation for memcg
type: item
description: Hello All, This is my new take for the memcg kmem accounting. At this point, I consider the series pretty mature - although of course, bugs are always there... As a disclaimer, however, I must say that the slub code is much more stressed by me, since I know it better. If you have no more objections to the concepts presented, the remaining edges can probably be polished in a rc cycle, at the maintainers discretion, of course. Otherwise, I'll be happy to address any concerns of yours. Since last submission: * 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 registered can be properly removed (common module case) even if it spans memcg children. Slab had some code for that, now it works well with both * A new mechanism for skipping allocations is proposed (patch posted separately already). Now instead of having kmalloc_no_account, we mark a region as non-accountable for memcg. 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. 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. Frederic Weisbecker (1): cgroups: ability to stop res charge propagation on bounded ancestor Glauber Costa (24): slab: dup name string slub: fix slab_state for slub memcg: Always free struct memcg through schedule_work() slub: always get the cache from its page in kfree slab: rename gfpflags to allocflags slab: use obj_size field of struct kmem_cache when not debugging memcg: change defines to an enum res_counter: don't force return value checking in res_counter_charge_nofail kmem slab accounting basic infrastructure slab/slub: struct memcg_params slub: consider a memcg parameter in kmem_create_cache slab: p…
creator: Glauber Costa
date: 2012-05-11T17:44:02-00:00

[PATCH v2 01/29] slab: dup name string
type: item
description: The slub allocator creates a copy of the name string, and frees it later. I would like them both to behave the same, whether it is the slab starting to create a copy of it itself, or the slub ceasing to. This is because when I create memcg copies of it, I have to kmalloc strings for the new names, and having the allocators to behave differently here, would make it a lot uglier. My first submission removed the duplication for the slub. But the code started to get a bit complicated when dealing with deletion of chained caches. Also, Christoph voiced his opinion that patching the slab to keep copies would be better. So here it is. Signed-off-by: Glauber Costa <glommer@parallels.com> CC: Christoph Lameter <cl@linux.com> CC: Pekka Enberg <penberg@cs.helsinki.fi> --- mm/slab.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/mm/slab.c b/mm/slab.c index e901a36..91b9c13 100644 --- a/mm/slab.c +++ b/mm/slab.c @@ -2118,6 +2118,7 @@ static void __kmem_cache_destroy(struct kmem_cache *cachep) kfree(l3); } } + kfree(cachep->name); kmem_cache_free(&cache_cache, cachep); } @@ -2526,7 +2527,7 @@ kmem_cache_create (const char *name, size_t size, size_t align, BUG_ON(ZERO_OR_NULL_PTR(cachep->slabp_cache)); } cachep->ctor = ctor; - cachep->name = name; + cachep->name = kstrdup(name, GFP_KERNEL); if (setup_cpu_cache(cachep, gfp)) { __kmem_cache_destroy(cachep); -- 1.7.7.6
creator: Glauber Costa
date: 2012-05-11T17:44:03-00:00

[PATCH v2 02/29] slub: fix slab_state for slub
type: item
description: When the slub code wants to know if the sysfs state has already been initialized, it tests for slab_state == SYSFS. This is quite fragile, since new state can be added in the future (it is, in fact, for memcg caches). This patch fixes this behavior so the test matches >= SYSFS, as all other state does. Signed-off-by: Glauber Costa <glommer@parallels.com> CC: Christoph Lameter <cl@linux.com> CC: Pekka Enberg <penberg@cs.helsinki.fi> --- mm/slub.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/mm/slub.c b/mm/slub.c index ffe13fd..226e053 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -5356,7 +5356,7 @@ static int sysfs_slab_alias(struct kmem_cache *s, const char *name) { struct saved_alias *al; - if (slab_state == SYSFS) { + if (slab_state >= SYSFS) { /* * If we have a leftover link then remove it. */ -- 1.7.7.6
creator: Glauber Costa
date: 2012-05-11T17:44:04-00:00

[PATCH v2 03/29] 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-11T17:44:05-00:00

[PATCH v2 04/29] 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 Signed-off-by: Glauber Costa <glommer@parallels.com> CC: Christoph Lameter <cl@linux.com> CC: Pekka Enberg <penberg@cs.helsinki.fi> --- mm/slub.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/mm/slub.c b/mm/slub.c index 226e053..e606f1b 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -2600,7 +2600,7 @@ void kmem_cache_free(struct kmem_cache *s, void *x) page = virt_to_head_page(x); - slab_free(s, page, x, _RET_IP_); + slab_free(page->slab, page, x, _RET_IP_); trace_kmem_cache_free(_RET_IP_, x); } -- 1.7.7.6
creator: Glauber Costa
date: 2012-05-11T17:44:06-00:00

[PATCH v2 05/29] 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> CC: 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 91b9c13..8a851ed 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; @@ -2509,9 +2509,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); @@ -2858,9 +2858,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-11T17:44:07-00:00

[PATCH v2 06/29] memcg: Make it possible to use the stock for more than one page.
type: item
description: From: Suleiman Souhlal <ssouhlal@FreeBSD.org> Signed-off-by: Suleiman Souhlal <suleiman@google.com> Signed-off-by: Glauber Costa <glommer@parallels.com> Acked-by: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> --- mm/memcontrol.c | 18 +++++++++--------- 1 files changed, 9 insertions(+), 9 deletions(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 0b4b4c8..248d80b 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -1998,19 +1998,19 @@ static DEFINE_PER_CPU(struct memcg_stock_pcp, memcg_stock); static DEFINE_MUTEX(percpu_charge_mutex); /* - * Try to consume stocked charge on this cpu. If success, one page is consumed - * from local stock and true is returned. If the stock is 0 or charges from a - * cgroup which is not current target, returns false. This stock will be - * refilled. + * Try to consume stocked charge on this cpu. If success, nr_pages pages are + * consumed from local stock and true is returned. If the stock is 0 or + * charges from a cgroup which is not current target, returns false. + * This stock will be refilled. */ -static bool consume_stock(struct mem_cgroup *memcg) +static bool consume_stock(struct mem_cgroup *memcg, int nr_pages) { struct memcg_stock_pcp *stock; bool ret = true; stock = &get_cpu_var(memcg_stock); - if (memcg == stock->cached && stock->nr_pages) - stock->nr_pages--; + if (memcg == stock->cached && stock->nr_pages >= nr_pages) + stock->nr_pages -= nr_pages; else /* need to call res_counter_charge */ ret = false; put_cpu_var(memcg_stock); @@ -2309,7 +2309,7 @@ again: VM_BUG_ON(css_is_removed(&memcg->css)); if (mem_cgroup_is_root(memcg)) goto done; - if (nr_pages == 1 && consume_stock(memcg)) + if (consume_stock(memcg, nr_pages)) goto done; css_get(&memcg->css); } else { @@ -2334,7 +2334,7 @@ again: rcu_read_unlock(); goto done; } - if (nr_pages == 1 && consume_stock(memcg)) { + if (consume_stock(memcg, nr_pages)) { /* * It seems dagerous to access memcg without css_get(). * But considering how consume_stok works, it's n…
creator: Glauber Costa
date: 2012-05-11T17:44:08-00:00

[PATCH v2 07/29] memcg: Reclaim when more than one page needed.
type: item
description: From: Suleiman Souhlal <ssouhlal@FreeBSD.org> mem_cgroup_do_charge() was written before slab accounting, and expects three cases: being called for 1 page, being called for a stock of 32 pages, or being called for a hugepage. If we call for 2 pages (and several slabs used in process creation are such, at least with the debug options I had), it assumed it's being called for stock and just retried without reclaiming. Fix that by passing down a minsize argument in addition to the csize. And what to do about that (csize == PAGE_SIZE && ret) retry? If it's needed at all (and presumably is since it's there, perhaps to handle races), then it should be extended to more than PAGE_SIZE, yet how far? And should there be a retry count limit, of what? For now retry up to COSTLY_ORDER (as page_alloc.c does), stay safe with a cond_resched(), and make sure not to do it if __GFP_NORETRY. Signed-off-by: Suleiman Souhlal <suleiman@google.com> Signed-off-by: Glauber Costa <glommer@parallels.com> Reviewed-by: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> --- mm/memcontrol.c | 18 +++++++++++------- 1 files changed, 11 insertions(+), 7 deletions(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 248d80b..47d3979 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -2187,7 +2187,8 @@ enum { }; static int mem_cgroup_do_charge(struct mem_cgroup *memcg, gfp_t gfp_mask, - unsigned int nr_pages, bool oom_check) + unsigned int nr_pages, unsigned int min_pages, + bool oom_check) { unsigned long csize = nr_pages * PAGE_SIZE; struct mem_cgroup *mem_over_limit; @@ -2210,18 +2211,18 @@ static int mem_cgroup_do_charge(struct mem_cgroup *memcg, gfp_t gfp_mask, } else mem_over_limit = mem_cgroup_from_res_counter(fail_res, res); /* - * nr_pages can be either a huge page (HPAGE_PMD_NR), a batch - * of regular pages (CHARGE_BATCH), or a single regular page (1). - * * Never reclaim on behalf of optional batching, retry with a * single page instead. */ - if (nr_pages == CHARGE_BATCH) + if (nr_pages…
creator: Glauber Costa
date: 2012-05-11T17:44:09-00:00

[PATCH v2 08/29] 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 8a851ed..56f2ba8 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-11T17:44:10-00:00

[PATCH v2 09/29] memcg: change defines to an enum
type: item
description: This is just a cleanup patch for clarity of expression. In earlier submissions, people asked it to be in a separate patch, so here it is. Signed-off-by: Glauber Costa <glommer@parallels.com> CC: Michal Hocko <mhocko@suse.cz> CC: Johannes Weiner <hannes@cmpxchg.org> Acked-by: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> --- mm/memcontrol.c | 9 ++++++--- 1 files changed, 6 insertions(+), 3 deletions(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 47d3979..789ca5a 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -374,9 +374,12 @@ enum charge_type { }; /* for encoding cft->private value on file */ -#define _MEM (0) -#define _MEMSWAP (1) -#define _OOM_TYPE (2) +enum res_type { + _MEM, + _MEMSWAP, + _OOM_TYPE, +}; + #define MEMFILE_PRIVATE(x, val) (((x) << 16) | (val)) #define MEMFILE_TYPE(val) (((val) >> 16) & 0xffff) #define MEMFILE_ATTR(val) ((val) & 0xffff) -- 1.7.7.6
creator: Glauber Costa
date: 2012-05-11T17:44:11-00:00

[PATCH v2 10/29] 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-11T17:44:12-00:00

[PATCH v2 11/29] cgroups: ability to stop res charge propagation on bounded ancestor
type: item
description: From: Frederic Weisbecker <fweisbec@gmail.com> Moving a task from a cgroup to another may require to substract its resource charge from the old cgroup and add it to the new one. For this to happen, the uncharge/charge propagation can just stop when we reach the common ancestor for the two cgroups. Further the performance reasons, we also want to avoid to temporarily overload the common ancestors with a non-accurate resource counter usage if we charge first the new cgroup and uncharge the old one thereafter. This is going to be a requirement for the coming max number of task subsystem. To solve this, provide a pair of new API that can charge/uncharge a resource counter until we reach a given ancestor. Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com> Acked-by: Paul Menage <paul@paulmenage.org> Acked-by: Glauber Costa <glommer@parallels.com> Cc: Li Zefan <lizf@cn.fujitsu.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Aditya Kali <adityakali@google.com> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Kay Sievers <kay.sievers@vrfy.org> Cc: Tim Hockin <thockin@hockin.org> Cc: Tejun Heo <htejun@gmail.com> Acked-by: Kirill A. Shutemov <kirill@shutemov.name> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> --- Documentation/cgroups/resource_counter.txt | 18 +++++++++++++++++- include/linux/res_counter.h | 21 ++++++++++++++++++--- kernel/res_counter.c | 13 ++++++++----- 3 files changed, 43 insertions(+), 9 deletions(-) diff --git a/Documentation/cgroups/resource_counter.txt b/Documentation/cgroups/resource_counter.txt index 95b24d7..a2cd05b 100644 --- a/Documentation/cgroups/resource_counter.txt +++ b/Documentation/cgroups/resource_counter.txt @@ -83,7 +83,15 @@ to work with it. res_counter->lock internally (it must be called with res_counter->lock held). - e. void res_counter_uncharge[_locked] + e. int res_counter_charge_until(struct res_counter *counter, + struct res_counter *limit, unsigned long val, + struct res_counter **limit_fail_at) + + The same as res_count…
creator: Glauber Costa
date: 2012-05-11T17:44:13-00:00

[PATCH v2 12/29] 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 | 79 ++++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 files changed, 78 insertions(+), 1 deletions(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 789ca5a..49b1129 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-11T17:44:14-00:00

[PATCH v2 13/29] 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> 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 | 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_NUMA /* --…
creator: Glauber Costa
date: 2012-05-11T17:44:15-00:00

[PATCH v2 14/29] 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 | 67 ++++++++++++++++++++++++++++++++++++++++--- 4 files changed, 109 insertions(+), 5 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/memcontr…
creator: Glauber Costa
date: 2012-05-11T17:44:16-00:00

[PATCH v2 15/29] 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 Signed-off-by: Glauber Costa <glommer@parallels.com> CC: Christoph Lameter <cl@linux.com> CC: Pekka Enberg <penberg@cs.helsinki.fi> CC: Michal Hocko <mhocko@suse.cz> CC: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> CC: Johannes Weiner <hannes@cmpxchg.org> CC: Suleiman Souhlal <suleiman@google.com> --- mm/slab.c | 74 ++++++++++++++++++++++++++++++++++++++++++++++++++++++------ 1 files changed, 66 insertions(+), 8 deletions(-) diff --git a/mm/slab.c b/mm/slab.c index 56f2ba8..d05a326 100644 --- a/mm/slab.c +++ b/mm/slab.c @@ -502,6 +502,9 @@ EXPORT_SYMBOL(slab_buffer_size); #define SLAB_MAX_ORDER_LO 0 static int slab_max_order = SLAB_MAX_ORDER_LO; static bool slab_max_order_set __initdata; +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM +static int slab_memcg_init __read_mostly; +#endif /* * Functions for storing/retrieving the cachep and or slab from the page @@ -2288,14 +2291,15 @@ static int __init_refok setup_cpu_cache(struct kmem_cache *cachep, gfp_t gfp) * cacheline. This can be beneficial if you're counting cycles as closely * as davem. */ -struct kmem_cache * -kmem_cache_create (const char *name, size_t size, size_t align, - unsigned long flags, void (*ctor)(void *)) +static struct kmem_cache * +__kmem_cache_create(struct mem_cgroup *memcg, const char *name, size_t size, + size_t align, unsigned long flags, void (*ctor)(void *)) { - size_t left_over, slab_size, ralign; + size_t left_over, orig_align, ralign, slab_size; struct kmem_cache *cachep = NULL, *pc; gfp_t gfp; + orig_align = align; /* * Sanity checks... these are all serious usage bugs. */ @@ -2312,7 +2316,6 @@ kmem_cache_create (const char *name, size_t size, size_t align, */ if (slab_is_available()) { ge…
creator: Glauber Costa
date: 2012-05-11T17:44:17-00:00

[PATCH v2 16/29] 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 | 31 +++++++++++++++++++++++++++++++ 4 files changed, 52 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 9327996..a8171cb 100644 --- a/mm/memcontrol.c +++ b/mm/mem…
creator: Glauber Costa
date: 2012-05-11T17:44:18-00:00

[PATCH v2 17/29] 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. Signed-off-by: Glauber Costa <glommer@parallels.com> CC: Christoph Lameter <cl@linux.com> CC: Pekka Enberg <penberg@cs.helsinki.fi> CC: Michal Hocko <mhocko@suse.cz> CC: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> CC: Johannes Weiner <hannes@cmpxchg.org> CC: Suleiman Souhlal <suleiman@google.com> --- mm/slab.c | 32 ++++++++++++++++++++++++++++++++ 1 files changed, 32 insertions(+), 0 deletions(-) diff --git a/mm/slab.c b/mm/slab.c index d05a326..985714a 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 @@ -2598,6 +2600,36 @@ 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); + 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) + goto out; + + if ((cachep->limit != new->limit) || + (cachep->batchcount != new->batchcount) || + (cachep->…
creator: Glauber Costa
date: 2012-05-11T17:44:19-00:00

[PATCH v2 18/29] 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. I apologize in advance to the reviewers. This patch is quite big, but I was not able to split it any further due to all the dependencies between the code. This code is inspired by the code written by Suleiman Souhlal, but heavily changed. 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 | 67 ++++++++ init/Kconfig | 2 +- mm/memcontrol.c | 379 +++++++++++++++++++++++++++++++++++++++++++- 3 files changed, 446 insertions(+), 2 deletions(-) diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h index f93021a..c555799 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.…
creator: Glauber Costa
date: 2012-05-11T17:44:20-00:00

[PATCH v2 19/29] 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..0501114 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; + atomic_t 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 5a7416b..c4ecf9c 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; + + atomic_inc(&current->memcg_kmem_skip_account); +} + +static void memcg_resume_kmem_account(void) +{ + if (!current->mm) + return; + + atomic_dec(&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_acco…
creator: Glauber Costa
date: 2012-05-11T17:44:21-00:00

[PATCH v2 20/29] 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 | 113 +++++++++++++++++++++++++++++++++++++++++----- 2 files changed, 135 insertions(+), 17 deletions(-) diff --git a/include/linux/slub_def.h b/include/linux/slub_def.h index 5f5e942..56b6fb4 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 */ @@ -210,27 +212,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); voi…
creator: Glauber Costa
date: 2012-05-11T17:44:22-00:00

[PATCH v2 21/29] 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> 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_def.h | 62 ++++++++++++++++++++++++++++ mm/slab.c | 102 +++++++++++++++++++++++++++++++++++++++++----- 2 files changed, 154 insertions(+), 10 deletions(-) diff --git a/include/linux/slab_def.h b/include/linux/slab_def.h index 06e4a3e..ed8c43c 100644 --- a/include/linux/slab_def.h +++ b/include/linux/slab_def.h @@ -218,4 +218,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_CGROUP_MEM_RE…
creator: Glauber Costa
date: 2012-05-11T17:44:23-00:00

[PATCH v2 22/29] 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 | 19 ++++++++++++++++++- 2 files changed, 21 insertions(+), 2 deletions(-) diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h index c555799..4000798 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 c4ecf9c..ad60648 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(mem_…
creator: Glauber Costa
date: 2012-05-11T17:44:24-00:00

[PATCH v2 23/29] 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 4000798..3e03f26 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 e73ef71..a03a4f2 100644 --- a/include/linux/slab.h +++ b/include/linux/slab.h @@ -164,6 +164,7 @@ struct mem_cgroup_cache_params { size_t orig_align; #endif + struct list_head destroyed_list; /* Used when deleting memcg cache */ }; #endif diff --git a/mm/memcontrol.c b/mm/memcontrol.c index ad60648..1d1a307 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -476,6 +476,11 @@ static void disarm_static_keys(struct mem_cgroup *memcg) { if (memcg->…
creator: Glauber Costa
date: 2012-05-11T17:44:25-00:00

[PATCH v2 24/29] 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 | 9 ++++++++ mm/memcontrol.c | 49 +++++++++++++++++++++++++++++++++++++++++++-- mm/slub.c | 1 + 4 files changed, 60 insertions(+), 3 deletions(-) diff --git a/include/linux/slab.h b/include/linux/slab.h index a03a4f2..d03637e 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 56b6fb4..7462b2e 100644 --- a/include/linux/slub_def.h +++ b/include/linux/slub_def.h @@ -117,6 +117,15 @@ struct kmem_cache { struc…
creator: Glauber Costa
date: 2012-05-11T17:44:26-00:00

[PATCH v2 25/29] memcg: Track all the memcg children of a kmem_cache.
type: item
description: From: Suleiman Souhlal <ssouhlal@FreeBSD.org> 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. Signed-off-by: Suleiman Souhlal <suleiman@google.com> --- include/linux/memcontrol.h | 1 + include/linux/slab.h | 1 + mm/memcontrol.c | 9 +++++++ mm/slab.c | 52 ++++++++++++++++++++++++++++++++++++++++--- 4 files changed, 59 insertions(+), 4 deletions(-) diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h index 3e03f26..5a5cd42 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 d03637e..876783b 100644 --- a/include/linux/slab.h +++ b/include/linux/slab.h @@ -169,6 +169,7 @@ struct mem_cgroup_cache_params { #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 c3772dc..933edf1 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -548,6 +548,7 @@ void mem_cgroup_register_cache(struct mem_cgroup *memcg, else INIT_LIST_HEAD(&cachep->memcg_params.destroyed_list); cachep->memcg_params.id = id; + INIT_LIST_HEAD(&cachep->memcg_params.sibling_list); } void mem_cgroup_release_cache(struct kmem_cache *cachep) @@ -845,6 +846,14 @@ struct kmem_cache *__mem_cgroup_get_kmem_cache(struct kmem_cache *cachep, } EXP…
creator: Glauber Costa
date: 2012-05-11T17:44:27-00:00

[PATCH v2 26/29] 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 876783b..e250111 100644 --- a/include/linux/slab.h +++ b/include/linux/slab.h @@ -330,6 +330,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 933edf1..6b49b5e 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -5223,6 +5223,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", @@ -5247,6 +5260,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 cd4600d..afc26df 100644 --- a/mm/slab.c +++ b/mm/slab.c @@ -4523,21 +4523,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-11T17:44:28-00:00

[PATCH v2 27/29] 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 0efcd77..afe29ef 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -4159,6 +4159,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-11T17:44:29-00:00

[PATCH v2 28/29] 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 | 61 +++++++++++++++++++++++++++++++++++++++++++++++------------- - 1 files changed, 47 insertions(+), 14 deletions(-) diff --git a/mm/slub.c b/mm/slub.c index afe29ef..cfa6295 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -3267,6 +3267,20 @@ static inline int kmem_cache_close(struct kmem_cache *s) return 0; } +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); +} + /* * Close a cache and release the kmem_cache structure * (must be used for caches created using kmem_cache_create) @@ -3275,24 +3289,41 @@ void kmem_cache_destroy(struct kmem_cache *s) { down_write(&slub_lock); s->refcount--; - if (!s->refcount) { - list_del(&s->list); + #ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM - /* Not a memcg cache */ - if (s->memcg_params.id != -1) { - mem_cgroup_release_cache(s); - mem_cgroup_flush_cache_create_queue(); + /* Not a memcg cache */ + if (s->memcg_params.id != …
creator: Glauber Costa
date: 2012-05-11T17:44:30-00:00

[PATCH v2 29/29] 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-11T17:44:31-00:00

Re: [PATCH v2 02/29] slub: fix slab_state for slub
type: item
description: Acked-by: Christoph Lameter <cl@linux.com>
creator: Christoph Lameter
date: 2012-05-11T17:51:10-00:00

Re: [PATCH v2 04/29] slub: always get the cache from its page in kfree
type: item
description: On Fri, 11 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 Other allocators may not have that information and this patch may cause bugs to go unnoticed if the caller specifies the wrong slab cache. Adding a VM_BUG_ON may be useful to make sure that kmem_cache_free is always passed the correct slab cache.
creator: Christoph Lameter
date: 2012-05-11T17:53:31-00:00

Re: [PATCH v2 05/29] slab: rename gfpflags to allocflags
type: item
description: On Fri, 11 May 2012, Glauber Costa wrote: > 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. Acked-by: Christoph Lameter <cl@linux.com>
creator: Christoph Lameter
date: 2012-05-11T17:54:03-00:00

Re: [PATCH v2 04/29] slub: always get the cache from its page in kfree
type: item
description: On 05/11/2012 02:53 PM, Christoph Lameter wrote: > On Fri, 11 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 > > Other allocators may not have that information and this patch may > cause bugs to go unnoticed if the caller specifies the wrong slab cache. > > Adding a VM_BUG_ON may be useful to make sure that kmem_cache_free is > always passed the correct slab cache. Well, problem is , it isn't always passed the "correct" slab cache. At least not after this series, since we'll have child caches associated with the main cache. So we'll pass, for instance, kmem_cache_free(dentry_cache...), but will in fact free from the memcg copy of the dentry cache. We can, of course, verify if the cache at least belongs to the same "family". But that's quite expensive.
creator: Glauber Costa
date: 2012-05-11T17:57:49-00:00

Re: [PATCH v2 00/29] kmem limitation for memcg
type: item
description: On 05/11/2012 02:44 PM, Glauber Costa wrote: > Hello All, > > This is my new take for the memcg kmem accounting. > At this point, I consider the series pretty mature - although of course, > bugs are always there... > > As a disclaimer, however, I must say that the slub code is much more stressed > by me, since I know it better. If you have no more objections to the concepts > presented, the remaining edges can probably be polished in a rc cycle, > at the maintainers discretion, of course. > > Otherwise, I'll be happy to address any concerns of yours. > > Since last submission: > > * 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 registered can be properly removed (common module case) > even if it spans memcg children. Slab had some code for that, now it works > well with both > * A new mechanism for skipping allocations is proposed (patch posted > separately already). Now instead of having kmalloc_no_account, we mark > a region as non-accountable for memcg. > Forgot to mention the ida-based index allocation, instead of keeping our own bitmap.
creator: Glauber Costa
date: 2012-05-11T18:05:21-00:00

Re: [PATCH v2 04/29] slub: always get the cache from its page in kfree
type: item
description: On Fri, 11 May 2012, Glauber Costa wrote: > > Adding a VM_BUG_ON may be useful to make sure that kmem_cache_free is > > always passed the correct slab cache. > > Well, problem is , it isn't always passed the "correct" slab cache. > At least not after this series, since we'll have child caches associated with > the main cache. > > So we'll pass, for instance, kmem_cache_free(dentry_cache...), but will in > fact free from the memcg copy of the dentry cache. Urg. But then please only do this for the MEMCG case and add a fat big warning in kmem_cache_free.
creator: Christoph Lameter
date: 2012-05-11T18:06:36-00:00

Re: [PATCH v2 04/29] slub: always get the cache from its page in kfree
type: item
description: On 05/11/2012 03:06 PM, Christoph Lameter wrote: > On Fri, 11 May 2012, Glauber Costa wrote: > >>> Adding a VM_BUG_ON may be useful to make sure that kmem_cache_free is >>> always passed the correct slab cache. >> >> Well, problem is , it isn't always passed the "correct" slab cache. >> At least not after this series, since we'll have child caches associated with >> the main cache. >> >> So we'll pass, for instance, kmem_cache_free(dentry_cache...), but will in >> fact free from the memcg copy of the dentry cache. > > Urg. But then please only do this for the MEMCG case and add a fat big > warning in kmem_cache_free. I can do that, of course. Another option if you don't oppose, is to add another field in the kmem_cache structure (I tried to keep them at a minimum), to record the parent cache we got created from. Then, it gets trivial to do the following: VM_BUG_ON(page->slab != s && page->slab != s->parent_cache);
creator: Glauber Costa
date: 2012-05-11T18:11:56-00:00

Re: [PATCH v2 04/29] slub: always get the cache from its page in kfree
type: item
description: On Fri, 11 May 2012, Glauber Costa wrote: > On 05/11/2012 03:06 PM, Christoph Lameter wrote: > > On Fri, 11 May 2012, Glauber Costa wrote: > > > > > > Adding a VM_BUG_ON may be useful to make sure that kmem_cache_free is > > > > always passed the correct slab cache. > > > > > > Well, problem is , it isn't always passed the "correct" slab cache. > > > At least not after this series, since we'll have child caches associated > > > with > > > the main cache. > > > > > > So we'll pass, for instance, kmem_cache_free(dentry_cache...), but will in > > > fact free from the memcg copy of the dentry cache. > > > > Urg. But then please only do this for the MEMCG case and add a fat big > > warning in kmem_cache_free. > > I can do that, of course. > Another option if you don't oppose, is to add another field in the kmem_cache > structure (I tried to keep them at a minimum), > to record the parent cache we got created from. > > Then, it gets trivial to do the following: > > VM_BUG_ON(page->slab != s && page->slab != s->parent_cache); Sounds ok but I need to catch up on what this whole memcg thing in slab allocators should accomplish in order to say something definite.
creator: Christoph Lameter
date: 2012-05-11T18:17:41-00:00

Re: [PATCH v2 04/29] slub: always get the cache from its page in kfree
type: item
description: On 05/11/2012 03:17 PM, Christoph Lameter wrote: > On Fri, 11 May 2012, Glauber Costa wrote: > >> On 05/11/2012 03:06 PM, Christoph Lameter wrote: >>> On Fri, 11 May 2012, Glauber Costa wrote: >>> >>>>> Adding a VM_BUG_ON may be useful to make sure that kmem_cache_free is >>>>> always passed the correct slab cache. >>>> >>>> Well, problem is , it isn't always passed the "correct" slab cache. >>>> At least not after this series, since we'll have child caches associated >>>> with >>>> the main cache. >>>> >>>> So we'll pass, for instance, kmem_cache_free(dentry_cache...), but will in >>>> fact free from the memcg copy of the dentry cache. >>> >>> Urg. But then please only do this for the MEMCG case and add a fat big >>> warning in kmem_cache_free. >> >> I can do that, of course. >> Another option if you don't oppose, is to add another field in the kmem_cache >> structure (I tried to keep them at a minimum), >> to record the parent cache we got created from. >> >> Then, it gets trivial to do the following: >> >> VM_BUG_ON(page->slab != s&& page->slab != s->parent_cache); > > Sounds ok but I need to catch up on what this whole memcg thing in slab > allocators should accomplish in order to say something definite. > Fair enough. Thank you in advance for your time reviewing this!
creator: Glauber Costa
date: 2012-05-11T18:20:10-00:00

Re: [PATCH v2 04/29] slub: always get the cache from its page in kfree
type: item
description: On Fri, 11 May 2012, Glauber Costa wrote: > Thank you in advance for your time reviewing this! Where do I find the rationale for all of this? Trouble is that pages can contain multiple objects f.e. so accounting of pages to groups is a bit fuzzy. I have not followed memcg too much since it is not relevant (actual it is potentially significantly harmful given the performance impact) to the work loads that I am using.
creator: Christoph Lameter
date: 2012-05-11T18:32:48-00:00

Re: [PATCH v2 04/29] slub: always get the cache from its page in kfree
type: item
description: On 05/11/2012 03:32 PM, Christoph Lameter wrote: > On Fri, 11 May 2012, Glauber Costa wrote: > >> Thank you in advance for your time reviewing this! > > Where do I find the rationale for all of this? Trouble is that pages can > contain multiple objects f.e. so accounting of pages to groups is a bit fuzzy. > I have not followed memcg too much since it is not relevant (actual > it is potentially significantly harmful given the performance > impact) to the work loads that I am using. > It's been spread during last discussions. The user-visible part is documented in the last patch, but I'll try to use this space here to summarize more of the internals (it can also go somewhere in the tree if needed): We want to limit the amount of kernel memory tasks inside a memory cgroup use. slab is not the only one of them, but it is quite significant. For that, the least invasive, and most reasonable way we found to do it, is to create a copy of each slab inside the memcg. Or almost: we lazy create them, so only slabs that are touched by the memcg are created. So we don't mix pages from multiple memcgs in the same cache - we believe that would be too confusing. /proc/slabinfo reflects this information, by listing the memcg-specific slabs. This also appears in a memcg-specific memory.kmem.slabinfo. Also note that accounting is not done until kernel memory is limited. And if no memcg is limited, the code is wrapped inside static_key branches. So it should be completely patched out if you don't put stuff inside memcg.
creator: Glauber Costa
date: 2012-05-11T18:42:42-00:00

Re: [PATCH v2 04/29] slub: always get the cache from its page in kfree
type: item
description: On Fri, 11 May 2012, Glauber Costa wrote: > So we don't mix pages from multiple memcgs in the same cache - we believe that > would be too confusing. Well subsystem create caches and other things that are shared between multiple processes. How can you track that? > /proc/slabinfo reflects this information, by listing the memcg-specific slabs. What about /sys/kernel/slab/*?
creator: Christoph Lameter
date: 2012-05-11T18:56:38-00:00

Re: [PATCH v2 04/29] slub: always get the cache from its page in kfree
type: item
description: On 05/11/2012 03:56 PM, Christoph Lameter wrote: > On Fri, 11 May 2012, Glauber Costa wrote: > >> So we don't mix pages from multiple memcgs in the same cache - we believe that >> would be too confusing. > > Well subsystem create caches and other things that are shared between > multiple processes. How can you track that? Each process that belongs to a memcg triggers the creation of a new child kmem cache. >> /proc/slabinfo reflects this information, by listing the memcg-specific slabs. > > What about /sys/kernel/slab/*? From the PoV of the global system, what you'll see is something like: dentry , dentry(2:memcg1), dentry(2:memcg2), etc. No attempt is made to provide any view of those caches in a logically grouped way - the global system can view them independently.
creator: Glauber Costa
date: 2012-05-11T18:58:49-00:00

Re: [PATCH v2 04/29] slub: always get the cache from its page in kfree
type: item
description: On Fri, 11 May 2012, Glauber Costa wrote: > On 05/11/2012 03:56 PM, Christoph Lameter wrote: > > On Fri, 11 May 2012, Glauber Costa wrote: > > > > > So we don't mix pages from multiple memcgs in the same cache - we believe > > > that > > > would be too confusing. > > > > Well subsystem create caches and other things that are shared between > > multiple processes. How can you track that? > > Each process that belongs to a memcg triggers the creation of a new child kmem > cache. I see that. But there are other subsystems from slab allocators that do the same. There are also objects that may be used by multiple processes. F.e what about shm? > > > /proc/slabinfo reflects this information, by listing the memcg-specific > > > slabs. > > > > What about /sys/kernel/slab/*? > > From the PoV of the global system, what you'll see is something like: > dentry , dentry(2:memcg1), dentry(2:memcg2), etc. Hmmm.. Would be better to have a hierachy there. /proc/slabinfo is more legacy.
creator: Christoph Lameter
date: 2012-05-11T19:09:15-00:00

Re: [PATCH v2 04/29] slub: always get the cache from its page in kfree
type: item
description: On 05/11/2012 04:09 PM, Christoph Lameter wrote: > On Fri, 11 May 2012, Glauber Costa wrote: > >> On 05/11/2012 03:56 PM, Christoph Lameter wrote: >>> On Fri, 11 May 2012, Glauber Costa wrote: >>> >>>> So we don't mix pages from multiple memcgs in the same cache - we believe >>>> that >>>> would be too confusing. >>> >>> Well subsystem create caches and other things that are shared between >>> multiple processes. How can you track that? >> >> Each process that belongs to a memcg triggers the creation of a new child kmem >> cache. > > I see that. But there are other subsystems from slab allocators that do > the same. There are also objects that may be used by multiple processes. This is also true for normal user pages. And then, we do what memcg does: first one to touch, gets accounted. I don't think deviating from the memcg behavior for user pages makes much sense here. A cache won't go away while it still have objects, even after the memcg is removed (it is marked as dead) > F.e what about shm? > >>>> /proc/slabinfo reflects this information, by listing the memcg-specific >>>> slabs. >>> >>> What about /sys/kernel/slab/*? >> >> From the PoV of the global system, what you'll see is something like: >> dentry , dentry(2:memcg1), dentry(2:memcg2), etc. > > Hmmm.. Would be better to have a hierachy there. /proc/slabinfo is more > legacy. I can take a look at that then. Assuming you agree with all the rest, is looking into that a pre-requisite for merging, or is something that can be deferred for a phase2 ? (We still don't do shrinkers, for instance, so this is sure to have a phase2)
creator: Glauber Costa
date: 2012-05-11T19:11:05-00:00

Re: [PATCH v2 04/29] slub: always get the cache from its page in kfree
type: item
description: On Fri, 11 May 2012, Glauber Costa wrote: > > I see that. But there are other subsystems from slab allocators that do > > the same. There are also objects that may be used by multiple processes. > > This is also true for normal user pages. And then, we do what memcg does: > first one to touch, gets accounted. I don't think deviating from the memcg > behavior for user pages makes much sense here. > > A cache won't go away while it still have objects, even after the memcg is > removed (it is marked as dead) Ok so we will have some dead pages around that are then repatriated to the / set? > > Hmmm.. Would be better to have a hierachy there. /proc/slabinfo is more > > legacy. > > I can take a look at that then. Assuming you agree with all the rest, is > looking into that a pre-requisite for merging, or is something that can be > deferred for a phase2 ? (We still don't do shrinkers, for instance, so this is > sure to have a phase2) Not a prerequisite for merging but note that I intend to rework the allocators to extract common code so that they have the same sysfs interface, error reporting and failure scenarios. We can at that time also add support for /sys/kernel/slab to memcg. (/sys/memcg/<name>/slab/* ?)
creator: Christoph Lameter
date: 2012-05-11T19:20:36-00:00

Re: [PATCH v2 04/29] slub: always get the cache from its page in kfree
type: item
description: On 05/11/2012 04:20 PM, Christoph Lameter wrote: > On Fri, 11 May 2012, Glauber Costa wrote: > >>> I see that. But there are other subsystems from slab allocators that do >>> the same. There are also objects that may be used by multiple processes. >> >> This is also true for normal user pages. And then, we do what memcg does: >> first one to touch, gets accounted. I don't think deviating from the memcg >> behavior for user pages makes much sense here. >> >> A cache won't go away while it still have objects, even after the memcg is >> removed (it is marked as dead) > > Ok so we will have some dead pages around that are then repatriated to > the / set? No, they are not repatriated. I actually wrote code for that once in my first series, but it was the general feeling at the time that it was too complicated. (and I only tried for the slub, not slab) So instead, we just keep the cache around, until the objects go away. It will show in slabinfo as dentry(css_id:memcgname)dead For the record, I wrote that code because I found a nice feature, but I totally agree with the complicated part. Also, in normal scenarios, dead caches are not expected to be common. Most of them should go away as memcg dies. >>> Hmmm.. Would be better to have a hierachy there. /proc/slabinfo is more >>> legacy. >> >> I can take a look at that then. Assuming you agree with all the rest, is >> looking into that a pre-requisite for merging, or is something that can be >> deferred for a phase2 ? (We still don't do shrinkers, for instance, so this is >> sure to have a phase2) > > Not a prerequisite for merging but note that I intend to rework the > allocators to extract common code so that they have the same sysfs > interface, error reporting and failure scenarios. We can at that time > also add support for /sys/kernel/slab to memcg. (/sys/memcg/<name>/slab/* ?) Yes, that would be a good plan.
creator: Glauber Costa
date: 2012-05-11T19:24:11-00:00

Re: [PATCH v2 19/29] skip memcg kmem allocations in specified code regions
type: item
description: (2012/05/12 2:44), Glauber Costa wrote: > This patch creates a mechanism that skip memcg allocations during > certain pieces of our core code. It basically works in the same way > as preempt_disable()/preempt_enable(): By marking a region under > which all allocations will be accounted to the root memcg. > > We need this to prevent races in early cache creation, when we > allocate data using caches that are not necessarily created already. > > 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> The concept seems okay to me but... > --- > 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..0501114 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; > + atomic_t memcg_kmem_skip_account; If only 'current' thread touch this, you don't need to make this atomic counter. you can use 'long'. Thanks, -Kame
creator: KAMEZAWA Hiroyuki
date: 2012-05-15T02:46:48-00:00

Re: [PATCH v2 18/29] memcg: kmem controller charge/uncharge infrastructure
type: item
description: (2012/05/12 2:44), Glauber Costa wrote: > 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. > > I apologize in advance to the reviewers. This patch is quite big, but > I was not able to split it any further due to all the dependencies > between the code. > > This code is inspired by the code written by Suleiman Souhlal, > but heavily changed. > > 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 | 67 ++++++++ > init/Kconfig | 2 +- > mm/memcontrol.c | 379 +++++++++++++++++++++++++++++++++++++++++++- > 3 files changed, 446 insertions(+), 2 deletions(-) > > diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h > index f93021a..c555799 100644 > --- a/include/linux/memcontrol.h >…
creator: KAMEZAWA Hiroyuki
date: 2012-05-15T02:57:35-00:00

Re: [PATCH v2 11/29] cgroups: ability to stop res charge propagation on bounded ancestor
type: item
description: (2012/05/12 2:44), Glauber Costa wrote: > From: Frederic Weisbecker <fweisbec@gmail.com> > > Moving a task from a cgroup to another may require to substract its > resource charge from the old cgroup and add it to the new one. > > For this to happen, the uncharge/charge propagation can just stop when we > reach the common ancestor for the two cgroups. Further the performance > reasons, we also want to avoid to temporarily overload the common > ancestors with a non-accurate resource counter usage if we charge first > the new cgroup and uncharge the old one thereafter. This is going to be a > requirement for the coming max number of task subsystem. > > To solve this, provide a pair of new API that can charge/uncharge a > resource counter until we reach a given ancestor. > > Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com> > Acked-by: Paul Menage <paul@paulmenage.org> > Acked-by: Glauber Costa <glommer@parallels.com> > Cc: Li Zefan <lizf@cn.fujitsu.com> > Cc: Johannes Weiner <hannes@cmpxchg.org> > Cc: Aditya Kali <adityakali@google.com> > Cc: Oleg Nesterov <oleg@redhat.com> > Cc: Kay Sievers <kay.sievers@vrfy.org> > Cc: Tim Hockin <thockin@hockin.org> > Cc: Tejun Heo <htejun@gmail.com> > Acked-by: Kirill A. Shutemov <kirill@shutemov.name> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Where is this function called in this series ? Thanks, -Kame
creator: KAMEZAWA Hiroyuki
date: 2012-05-15T02:59:45-00:00

Re: [PATCH v2 02/29] slub: fix slab_state for slub
type: item
description: On Fri, 11 May 2012, Glauber Costa wrote: > When the slub code wants to know if the sysfs state has already been > initialized, it tests for slab_state == SYSFS. This is quite fragile, > since new state can be added in the future (it is, in fact, for > memcg caches). This patch fixes this behavior so the test matches > >= SYSFS, as all other state does. > > Signed-off-by: Glauber Costa <glommer@parallels.com> Acked-by: David Rientjes <rientjes@google.com> Can be merged now, there's no dependency on the rest of this patchset.
creator: David Rientjes
date: 2012-05-15T21:55:04-00:00

Re: [PATCH v2 05/29] slab: rename gfpflags to allocflags
type: item
description: On Fri, 11 May 2012, Glauber Costa wrote: > 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: David Rientjes <rientjes@google.com> Same, can be merged now with no dependency on the rest of this patchset.
creator: David Rientjes
date: 2012-05-15T21:57:05-00:00

Re: [PATCH v2 01/29] slab: dup name string
type: item
description: On Fri, 11 May 2012, Glauber Costa wrote: > diff --git a/mm/slab.c b/mm/slab.c > index e901a36..91b9c13 100644 > --- a/mm/slab.c > +++ b/mm/slab.c > @@ -2118,6 +2118,7 @@ static void __kmem_cache_destroy(struct kmem_cache *cachep) > kfree(l3); > } > } > + kfree(cachep->name); > kmem_cache_free(&cache_cache, cachep); > } > > @@ -2526,7 +2527,7 @@ kmem_cache_create (const char *name, size_t size, size_t align, > BUG_ON(ZERO_OR_NULL_PTR(cachep->slabp_cache)); > } > cachep->ctor = ctor; > - cachep->name = name; > + cachep->name = kstrdup(name, GFP_KERNEL); > > if (setup_cpu_cache(cachep, gfp)) { > __kmem_cache_destroy(cachep); Couple problems: - allocating memory for a string of an unknown, unchecked size, and - could potentially return NULL which I suspect will cause problems later.
creator: David Rientjes
date: 2012-05-15T22:04:14-00:00

Re: [PATCH v2 02/29] slub: fix slab_state for slub
type: item
description: On 05/16/2012 01:55 AM, David Rientjes wrote: > On Fri, 11 May 2012, Glauber Costa wrote: > >> When the slub code wants to know if the sysfs state has already been >> initialized, it tests for slab_state == SYSFS. This is quite fragile, >> since new state can be added in the future (it is, in fact, for >> memcg caches). This patch fixes this behavior so the test matches >>> = SYSFS, as all other state does. >> >> Signed-off-by: Glauber Costa<glommer@parallels.com> > > Acked-by: David Rientjes<rientjes@google.com> > > Can be merged now, there's no dependency on the rest of this patchset. Agreed. If anyone is willing to, would make my life easier in the future. Valid for all patches that fall in this category (there are quite a few in the purely memcg land as well)
creator: Glauber Costa
date: 2012-05-16T06:10:24-00:00

Re: [PATCH v2 01/29] slab: dup name string
type: item
description: On 05/16/2012 02:04 AM, David Rientjes wrote: > On Fri, 11 May 2012, Glauber Costa wrote: > >> diff --git a/mm/slab.c b/mm/slab.c >> index e901a36..91b9c13 100644 >> --- a/mm/slab.c >> +++ b/mm/slab.c >> @@ -2118,6 +2118,7 @@ static void __kmem_cache_destroy(struct kmem_cache *cachep) >> kfree(l3); >> } >> } >> + kfree(cachep->name); >> kmem_cache_free(&cache_cache, cachep); >> } >> >> @@ -2526,7 +2527,7 @@ kmem_cache_create (const char *name, size_t size, size_t align, >> BUG_ON(ZERO_OR_NULL_PTR(cachep->slabp_cache)); >> } >> cachep->ctor = ctor; >> - cachep->name = name; >> + cachep->name = kstrdup(name, GFP_KERNEL); >> >> if (setup_cpu_cache(cachep, gfp)) { >> __kmem_cache_destroy(cachep); > > Couple problems: > > - allocating memory for a string of an unknown, unchecked size, and > > - could potentially return NULL which I suspect will cause problems > later. Well, this is what slub does. I sent already two patches for it: One removing this from the slub, one adding this to the slab. Right now I am comfortable with this one, because it makes it slightly easier in the latest patches of my series. But note the word: slightest. I am comfortable with any, provided slub and slab start behaving the same. So whatever you guys decide between yourselves is fine, provided there is a decision. Thanks for your review, David!
creator: Glauber Costa
date: 2012-05-16T06:12:04-00:00

Re: [PATCH v2 11/29] cgroups: ability to stop res charge propagation on bounded ancestor
type: item
description: On 05/15/2012 06:59 AM, KAMEZAWA Hiroyuki wrote: > (2012/05/12 2:44), Glauber Costa wrote: > >> From: Frederic Weisbecker<fweisbec@gmail.com> >> >> Moving a task from a cgroup to another may require to substract its >> resource charge from the old cgroup and add it to the new one. >> >> For this to happen, the uncharge/charge propagation can just stop when we >> reach the common ancestor for the two cgroups. Further the performance >> reasons, we also want to avoid to temporarily overload the common >> ancestors with a non-accurate resource counter usage if we charge first >> the new cgroup and uncharge the old one thereafter. This is going to be a >> requirement for the coming max number of task subsystem. >> >> To solve this, provide a pair of new API that can charge/uncharge a >> resource counter until we reach a given ancestor. >> >> Signed-off-by: Frederic Weisbecker<fweisbec@gmail.com> >> Acked-by: Paul Menage<paul@paulmenage.org> >> Acked-by: Glauber Costa<glommer@parallels.com> >> Cc: Li Zefan<lizf@cn.fujitsu.com> >> Cc: Johannes Weiner<hannes@cmpxchg.org> >> Cc: Aditya Kali<adityakali@google.com> >> Cc: Oleg Nesterov<oleg@redhat.com> >> Cc: Kay Sievers<kay.sievers@vrfy.org> >> Cc: Tim Hockin<thockin@hockin.org> >> Cc: Tejun Heo<htejun@gmail.com> >> Acked-by: Kirill A. Shutemov<kirill@shutemov.name> >> Signed-off-by: Andrew Morton<akpm@linux-foundation.org> > > > Where is this function called in this series ? > > Thanks, > -Kame > It is not... anymore! But I forgot the patch among the "pre-requisite" patches I had. Thanks, this can be dropped.
creator: Glauber Costa
date: 2012-05-16T06:16:51-00:00

Re: [PATCH v2 19/29] skip memcg kmem allocations in specified code regions
type: item
description: On 05/15/2012 06:46 AM, KAMEZAWA Hiroyuki wrote: > (2012/05/12 2:44), Glauber Costa wrote: > >> This patch creates a mechanism that skip memcg allocations during >> certain pieces of our core code. It basically works in the same way >> as preempt_disable()/preempt_enable(): By marking a region under >> which all allocations will be accounted to the root memcg. >> >> We need this to prevent races in early cache creation, when we >> allocate data using caches that are not necessarily created already. >> >> 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> > > > The concept seems okay to me but... > >> --- >> 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..0501114 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; >> + atomic_t memcg_kmem_skip_account; > > > If only 'current' thread touch this, you don't need to make this atomic counter. > you can use 'long'. > You're absolutely right, Kame, thanks. I first used atomic_t because I had it tested against current->mm->owner. Do you, btw, agree to use current instead of owner here? You can find the rationale in earlier mails between me and Suleiman.
creator: Glauber Costa
date: 2012-05-16T06:19:15-00:00

Re: [PATCH v2 18/29] memcg: kmem controller charge/uncharge infrastructure
type: item
description: On 05/15/2012 06:57 AM, KAMEZAWA Hiroyuki wrote: >> +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM >> > +int memcg_charge_kmem(struct mem_cgroup *memcg, gfp_t gfp, s64 delta) >> > +{ >> > + struct res_counter *fail_res; >> > + struct mem_cgroup *_memcg; >> > + int may_oom, ret; >> > + bool nofail = false; >> > + >> > + may_oom = (gfp& __GFP_WAIT)&& (gfp& __GFP_FS)&& >> > + !(gfp& __GFP_NORETRY); >> > + >> > + ret = 0; >> > + >> > + if (!memcg) >> > + return ret; >> > + >> > + _memcg = memcg; >> > + ret = __mem_cgroup_try_charge(NULL, gfp, delta / PAGE_SIZE, >> > + &_memcg, may_oom); >> > + >> > + if ((ret == -EINTR) || (ret&& (gfp& __GFP_NOFAIL))) { >> > + nofail = true; >> > + /* >> > + * __mem_cgroup_try_charge() chose to bypass to root due >> > + * to OOM kill or fatal signal. >> > + * Since our only options are to either fail the >> > + * allocation or charge it to this cgroup, force the >> > + * change, going above the limit if needed. >> > + */ >> > + res_counter_charge_nofail(&memcg->res, delta,&fail_res); >> > + if (do_swap_account) >> > + res_counter_charge_nofail(&memcg->memsw, delta, >> > + &fail_res); >> > + } else if (ret == -ENOMEM) >> > + return ret; >> > + >> > + if (nofail) >> > + res_counter_charge_nofail(&memcg->kmem, delta,&fail_res); >> > + else >> > + ret = res_counter_charge(&memcg->kmem, delta,&fail_res); > > Ouch, you allow usage> limit ? It's BUG. > > IMHO, if GFP_NOFAIL, memcg accounting should be skipped. Please > > if (gfp_mask& __GFP_NOFAIL) > return 0; > > Or avoid calling memcg_charge_kmem() you can do that as you do in patch 19/29, > I guess you can use a trick like > > == in 19/29 > + if (!current->mm || atomic_read(&current->memcg_kmem_skip_account)) > + return cachep; > + > gfp |= cachep->allocflags; > == > > == change like this > gfp |= cachep->allocflags; > > if (!current->mm || current->memcg_kmem_skip_account || gfp& __GFP_NOFAIL)) > == > > Is this difficult ? > > Thanks, > -Kame Well, we disagree with that. I actually voiced this ea…
creator: Glauber Costa
date: 2012-05-16T06:42:05-00:00

Re: [PATCH v2 19/29] skip memcg kmem allocations in specified code regions
type: item
description: (2012/05/16 15:19), Glauber Costa wrote: > On 05/15/2012 06:46 AM, KAMEZAWA Hiroyuki wrote: >> (2012/05/12 2:44), Glauber Costa wrote: >> >>> This patch creates a mechanism that skip memcg allocations during >>> certain pieces of our core code. It basically works in the same way >>> as preempt_disable()/preempt_enable(): By marking a region under >>> which all allocations will be accounted to the root memcg. >>> >>> We need this to prevent races in early cache creation, when we >>> allocate data using caches that are not necessarily created already. >>> >>> 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> >> >> >> The concept seems okay to me but... >> >>> --- >>> 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..0501114 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; >>> + atomic_t memcg_kmem_skip_account; >> >> >> If only 'current' thread touch this, you don't need to make this atomic counter. >> you can use 'long'. >> > You're absolutely right, Kame, thanks. > I first used atomic_t because I had it tested against current->mm->owner. > > Do you, btw, agree to use current instead of owner here? > You can find the rationale in earlier mails between me and Suleiman. I agree to use current. This information depends on the context of callers. Thanks, -Kame
creator: KAMEZAWA Hiroyuki
date: 2012-05-16T07:55:49-00:00

Re: [PATCH v2 18/29] memcg: kmem controller charge/uncharge infrastructure
type: item
description: (2012/05/16 15:42), Glauber Costa wrote: > On 05/15/2012 06:57 AM, KAMEZAWA Hiroyuki wrote: >>> +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM >>>> +int memcg_charge_kmem(struct mem_cgroup *memcg, gfp_t gfp, s64 delta) >>>> +{ >>>> + struct res_counter *fail_res; >>>> + struct mem_cgroup *_memcg; >>>> + int may_oom, ret; >>>> + bool nofail = false; >>>> + >>>> + may_oom = (gfp& __GFP_WAIT)&& (gfp& __GFP_FS)&& >>>> + !(gfp& __GFP_NORETRY); >>>> + >>>> + ret = 0; >>>> + >>>> + if (!memcg) >>>> + return ret; >>>> + >>>> + _memcg = memcg; >>>> + ret = __mem_cgroup_try_charge(NULL, gfp, delta / PAGE_SIZE, >>>> + &_memcg, may_oom); >>>> + >>>> + if ((ret == -EINTR) || (ret&& (gfp& __GFP_NOFAIL))) { >>>> + nofail = true; >>>> + /* >>>> + * __mem_cgroup_try_charge() chose to bypass to root due >>>> + * to OOM kill or fatal signal. >>>> + * Since our only options are to either fail the >>>> + * allocation or charge it to this cgroup, force the >>>> + * change, going above the limit if needed. >>>> + */ >>>> + res_counter_charge_nofail(&memcg->res, delta,&fail_res); >>>> + if (do_swap_account) >>>> + res_counter_charge_nofail(&memcg->memsw, delta, >>>> + &fail_res); >>>> + } else if (ret == -ENOMEM) >>>> + return ret; >>>> + >>>> + if (nofail) >>>> + res_counter_charge_nofail(&memcg->kmem, delta,&fail_res); >>>> + else >>>> + ret = res_counter_charge(&memcg->kmem, delta,&fail_res); >> >> Ouch, you allow usage> limit ? It's BUG. >> >> IMHO, if GFP_NOFAIL, memcg accounting should be skipped. Please >> >> if (gfp_mask& __GFP_NOFAIL) >> return 0; >> >> Or avoid calling memcg_charge_kmem() you can do that as you do in patch 19/29, >> I guess you can use a trick like >> >> == in 19/29 >> + if (!current->mm || atomic_read(&current->memcg_kmem_skip_account)) >> + return cachep; >> + >> gfp |= cachep->allocflags; >> == >> >> == change like this >> gfp |= cachep->allocflags; >> >> if (!current->mm || current->memcg_kmem_skip_account || gfp& __GFP_NOFAIL)) >> == >> >> Is this difficult ? >> >>…
creator: KAMEZAWA Hiroyuki
date: 2012-05-16T08:18:28-00:00

Re: [PATCH v2 18/29] memcg: kmem controller charge/uncharge infrastructure
type: item
description: On 05/16/2012 12:18 PM, KAMEZAWA Hiroyuki wrote: >> If at this point the memcg hits a NOFAIL allocation worth 2 pages, by >> > the method I am using, the memcg will be at 4M + 4k after the >> > allocation. Charging it to the root memcg will leave it at 4M - 4k. >> > >> > This means that to be able to allocate a page again, you need to free >> > two other pages, be it the 2 pages used by the GFP allocation or any >> > other. In other words: the memcg that originated the charge is held >> > accountable for it. If he says it can't fail for whatever reason, fine, >> > we respect that, but we punish it later for other allocations. >> > > I personally think 'we punish it later' is bad thing at resource accounting. > We have 'hard limit'. It's not soft limit. That only makes sense if you will fail the allocation. If you won't, you are over your hard limit anyway. You are just masquerading that. >> > Without that GFP_NOFAIL becomes just a nice way for people to bypass >> > those controls altogether, since after a ton of GFP_NOFAIL allocations, >> > normal allocations will still succeed. >> > > Allowing people to bypass is not bad because they're kernel. No, they are not. They are in process context, on behalf of a process that belongs to a valid memcg. If they happen to be a kernel thread, !current->mm test will send the allocation to the root memcg already. > > But, IIUC, from gfp.h > == > * __GFP_NOFAIL: The VM implementation_must_ retry infinitely: the caller > * cannot handle allocation failures. This modifier is deprecated and no new > * users should be added. > == > > GFP_NOFAIL will go away and no new user is recommended. > Yes, I am aware of that. That's actually why I don't plan to insist on this too much - although your e-mail didn't really convince me. It should not matter in practice. > So, please skip GFP_NOFAIL accounting and avoid to write > "usage may go over limit if you're unfortune, sorry" into memcg documentation. I won't write that, because that's not t…
creator: Glauber Costa
date: 2012-05-16T08:25:42-00:00

Re: [PATCH v2 18/29] memcg: kmem controller charge/uncharge infrastructure
type: item
description: (2012/05/16 17:25), Glauber Costa wrote: > On 05/16/2012 12:18 PM, KAMEZAWA Hiroyuki wrote: >>> If at this point the memcg hits a NOFAIL allocation worth 2 pages, by >>>> the method I am using, the memcg will be at 4M + 4k after the >>>> allocation. Charging it to the root memcg will leave it at 4M - 4k. >>>> >>>> This means that to be able to allocate a page again, you need to free >>>> two other pages, be it the 2 pages used by the GFP allocation or any >>>> other. In other words: the memcg that originated the charge is held >>>> accountable for it. If he says it can't fail for whatever reason, fine, >>>> we respect that, but we punish it later for other allocations. >>>> >> I personally think 'we punish it later' is bad thing at resource accounting. >> We have 'hard limit'. It's not soft limit. > > That only makes sense if you will fail the allocation. If you won't, you > are over your hard limit anyway. You are just masquerading that. > 'showing usage > limit to user' and 'avoid accounting' is totally different user experience. >>>> Without that GFP_NOFAIL becomes just a nice way for people to bypass >>>> those controls altogether, since after a ton of GFP_NOFAIL allocations, >>>> normal allocations will still succeed. >>>> >> Allowing people to bypass is not bad because they're kernel. > > No, they are not. They are in process context, on behalf of a process > that belongs to a valid memcg. If they happen to be a kernel thread, > !current->mm test will send the allocation to the root memcg already. > Yes, but it's kernel code. There will be some special reason to use __GFP_NOFAIL. >> >> But, IIUC, from gfp.h >> == >> * __GFP_NOFAIL: The VM implementation_must_ retry infinitely: the caller >> * cannot handle allocation failures. This modifier is deprecated and no new >> * users should be added. >> == >> >> GFP_NOFAIL will go away and no new user is recommended. >> > Yes, I am aware of that. That's actually why I don't plan to insist on > this too much - although…
creator: KAMEZAWA Hiroyuki
date: 2012-05-16T09:15:37-00:00

Re: [PATCH v2 02/29] slub: fix slab_state for slub
type: item
description: On 05/16/2012 01:55 AM, David Rientjes wrote: > On Fri, 11 May 2012, Glauber Costa wrote: > >> When the slub code wants to know if the sysfs state has already been >> initialized, it tests for slab_state == SYSFS. This is quite fragile, >> since new state can be added in the future (it is, in fact, for >> memcg caches). This patch fixes this behavior so the test matches >>> = SYSFS, as all other state does. >> >> Signed-off-by: Glauber Costa<glommer@parallels.com> > > Acked-by: David Rientjes<rientjes@google.com> > > Can be merged now, there's no dependency on the rest of this patchset. So, is anyone taking this? I plan another submission this week, let me know if I should include these two patches or not.
creator: Glauber Costa
date: 2012-05-17T10:14:18-00:00