OpenVZ Forum - RDF feed
type: channel
items: [PATCH v5 00/14] kmem controller for memcg.
items: [PATCH v5 01/14] memcg: Make it possible to use the stock for more than one page.
items: [PATCH v5 03/14] memcg: change defines to an enum
items: [PATCH v5 04/14] kmem accounting basic infrastructure
items: [PATCH v5 05/14] Add a __GFP_KMEMCG flag
items: [PATCH v5 06/14] memcg: kmem controller infrastructure
items: [PATCH v5 07/14] mm: Allocate kernel pages to the right memcg
items: [PATCH v5 09/14] memcg: kmem accounting lifecycle management
items: [PATCH v5 10/14] memcg: use static branches when code not in use
items: [PATCH v5 11/14] memcg: allow a memcg with kmem charges to be destructed.
items: [PATCH v5 13/14] protect architectures where THREAD_SIZE &gt;= PAGE_SIZE against fork bombs
items: [PATCH v5 14/14] Add documentation about the kmem controller
items: Re: [PATCH v5 04/14] kmem accounting basic infrastructure
items: Re: [PATCH v5 05/14] Add a __GFP_KMEMCG flag
items: Re: [PATCH v5 14/14] Add documentation about the kmem controller
items: Re: [PATCH v5 07/14] mm: Allocate kernel pages to the right memcg
items: Re: [PATCH v5 06/14] memcg: kmem controller infrastructure
items: Re: [PATCH v5 03/14] memcg: change defines to an enum
items: Re: [PATCH v5 00/14] kmem controller for memcg.
items: Re: [PATCH v5 01/14] memcg: Make it possible to use the stock for more than one page.
items: Re: [PATCH v5 11/14] memcg: allow a memcg with kmem charges to be destructed.
items: Re: [PATCH v5 13/14] protect architectures where THREAD_SIZE &gt;= PAGE_SIZE against fork bombs
items: Re: [PATCH v5 09/14] memcg: kmem accounting lifecycle management

[PATCH v5 00/14] kmem controller for memcg.
type: item
description: Hi, This is the first part of the kernel memory controller for memcg. It has been discussed many times, and I consider this stable enough to be on tree. A follow up to this series are the patches to also track slab memory. They are not included here because I believe we could benefit from merging them separately for better testing coverage. If there are any issues preventing this to be merged, let me know. I'll be happy to address them. *v5: - changed charged order, kmem charged first. - minor nits and comments merged. *v4: - kmem_accounted can no longer become unlimited - kmem_accounted can no longer become limited, if group has children. - documentation moved to this patchset - more style changes - css_get in charge path to ensure task won't move during charge *v3: - Changed function names to match memcg's - avoid doing get/put in charge/uncharge path - revert back to keeping the account enabled after it is first activated Numbers can be found at https://lkml.org/lkml/2012/9/13/239 A (throwaway) git tree with them is placed at: git://git.kernel.org/pub/scm/linux/kernel/git/glommer/memcg. git kmemcg-stack A general explanation of what this is all about follows: The kernel memory limitation mechanism for memcg concerns itself with disallowing potentially non-reclaimable allocations to happen in exaggerate quantities by a particular set of processes (cgroup). Those allocations could create pressure that affects the behavior of a different and unrelated set of processes. Its basic working mechanism is to annotate some allocations with the _GFP_KMEMCG flag. When this flag is set, the current process allocating will have its memcg identified and charged against. When reaching a specific limit, further allocations will be denied. One example of such problematic pressure that can be prevented by this work is a fork bomb conducted in a shell. We prevent it by noting that processes use a limited amount of stack pages. Seen this way, a fork bomb is just a special case of res…
creator: Glauber Costa
date: 2012-10-16T10:16:37-00:00

[PATCH v5 01/14] memcg: Make it possible to use the stock for more than one page.
type: item
description: From: Suleiman Souhlal <ssouhlal@FreeBSD.org> We currently have a percpu stock cache scheme that charges one page at a time from memcg->res, the user counter. When the kernel memory controller comes into play, we'll need to charge more than that. This is because kernel memory allocations will also draw from the user counter, and can be bigger than a single page, as it is the case with the stack (usually 2 pages) or some higher order slabs. [ glommer@parallels.com: added a changelog ] Signed-off-by: Suleiman Souhlal <suleiman@google.com> Signed-off-by: Glauber Costa <glommer@parallels.com> Acked-by: David Rientjes <rientjes@google.com> Acked-by: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Acked-by: Michal Hocko <mhocko@suse.cz> Acked-by: Johannes Weiner <hannes@cmpxchg.org> CC: Tejun Heo <tj@kernel.org> --- mm/memcontrol.c | 28 ++++++++++++++++++---------- 1 file changed, 18 insertions(+), 10 deletions(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 7acf43b..47cb019 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -2028,20 +2028,28 @@ struct memcg_stock_pcp { 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. +/** + * consume_stock: Try to consume stocked charge on this cpu. + * @memcg: memcg to consume from. + * @nr_pages: how many pages to charge. + * + * The charges will only happen if @memcg matches the current cpu's memcg + * stock, and at least @nr_pages are available in that stock. Failure to + * service an allocation will refill the stock. + * + * returns true if succesfull, false otherwise. */ -static bool consume_stock(struct mem_cgroup *memcg) +static bool consume_stock(struct mem_cgroup *memcg, int nr_pages) { struct memcg_stock_pcp *stock…
creator: Glauber Costa
date: 2012-10-16T10:16:38-00:00

[PATCH v5 03/14] 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. [ v2: use named enum as type throughout the file as well ] Signed-off-by: Glauber Costa <glommer@parallels.com> Acked-by: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Acked-by: Michal Hocko <mhocko@suse.cz> Acked-by: Johannes Weiner <hannes@cmpxchg.org> CC: Tejun Heo <tj@kernel.org> --- mm/memcontrol.c | 26 ++++++++++++++++---------- 1 file changed, 16 insertions(+), 10 deletions(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 7a9652a..71d259e 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -386,9 +386,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) @@ -3915,7 +3918,8 @@ static ssize_t mem_cgroup_read(struct cgroup *cont, struct cftype *cft, struct mem_cgroup *memcg = mem_cgroup_from_cont(cont); char str[64]; u64 val; - int type, name, len; + int name, len; + enum res_type type; type = MEMFILE_TYPE(cft->private); name = MEMFILE_ATTR(cft->private); @@ -3951,7 +3955,8 @@ static int mem_cgroup_write(struct cgroup *cont, struct cftype *cft, const char *buffer) { struct mem_cgroup *memcg = mem_cgroup_from_cont(cont); - int type, name; + enum res_type type; + int name; unsigned long long val; int ret; @@ -4027,7 +4032,8 @@ out: static int mem_cgroup_reset(struct cgroup *cont, unsigned int event) { struct mem_cgroup *memcg = mem_cgroup_from_cont(cont); - int type, name; + int name; + enum res_type type; type = MEMFILE_TYPE(event); name = MEMFILE_ATTR(event); @@ -4363,7 +4369,7 @@ static int mem_cgroup_usage_register_event(struct cgroup *cgrp, struct mem_cgroup *memcg = mem_cgroup_from_cont(cgrp); struct mem_cgroup_thresholds *threshol…
creator: Glauber Costa
date: 2012-10-16T10:16:40-00:00

[PATCH v5 04/14] kmem accounting basic infrastructure
type: item
description: This patch adds the basic infrastructure for the accounting of kernel memory. 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. Per cgroup kmem memory accounting is not enabled until a limit is set for the group. Once the limit is set the accounting cannot be disabled for that group. This means that after the patch is applied, no behavioral changes exists for whoever is still using memcg to control their memory usage, until memory.kmem.limit_in_bytes is set for the first time. 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) [ v4: make kmem files part of the main array; do not allow limit to be set for non-empty cgroups ] [ v5: cosmetic changes ] Signed-off-by: Glauber Costa <glommer@parallels.com> Acked-by: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> CC: Michal Hocko <mhocko@suse.cz> CC: Johannes Weiner <hannes@cmpxchg.org> CC: Tejun Heo <tj@kernel.org> --- mm/memcontrol.c | 116 +++++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 115 insertions(+), 1 deletion(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 71d259e..30eafeb 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -266,6 +266,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 li…
creator: Glauber Costa
date: 2012-10-16T10:16:41-00:00

[PATCH v5 05/14] Add a __GFP_KMEMCG flag
type: item
description: This flag is used to indicate to the callees that this allocation is a kernel allocation in process context, and should be accounted to current's memcg. It takes numerical place of the of the recently removed __GFP_NO_KSWAPD. [ v4: make flag unconditional, also declare it in trace code ] Signed-off-by: Glauber Costa <glommer@parallels.com> Acked-by: Johannes Weiner <hannes@cmpxchg.org> Acked-by: Rik van Riel <riel@redhat.com> Acked-by: Mel Gorman <mel@csn.ul.ie> Acked-by: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> CC: Christoph Lameter <cl@linux.com> CC: Pekka Enberg <penberg@cs.helsinki.fi> CC: Michal Hocko <mhocko@suse.cz> CC: Suleiman Souhlal <suleiman@google.com> CC: Tejun Heo <tj@kernel.org> --- include/linux/gfp.h | 3 ++- include/trace/events/gfpflags.h | 1 + 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/include/linux/gfp.h b/include/linux/gfp.h index 02c1c97..9289d46 100644 --- a/include/linux/gfp.h +++ b/include/linux/gfp.h @@ -31,6 +31,7 @@ struct vm_area_struct; #define ___GFP_THISNODE 0x40000u #define ___GFP_RECLAIMABLE 0x80000u #define ___GFP_NOTRACK 0x200000u +#define ___GFP_KMEMCG 0x400000u #define ___GFP_OTHER_NODE 0x800000u #define ___GFP_WRITE 0x1000000u @@ -87,7 +88,7 @@ struct vm_area_struct; #define __GFP_OTHER_NODE ((__force gfp_t)___GFP_OTHER_NODE) /* On behalf of other node */ #define __GFP_WRITE ((__force gfp_t)___GFP_WRITE) /* Allocator intends to dirty page */ - +#define __GFP_KMEMCG ((__force gfp_t)___GFP_KMEMCG) /* Allocation comes from a memcg-accounted resource */ /* * This may seem redundant, but it's a way of annotating false positives vs. * allocations that simply cannot be supported (e.g. page tables). diff --git a/include/trace/events/gfpflags.h b/include/trace/events/gfpflags.h index 9391706..730df12 100644 --- a/include/trace/events/gfpflags.h +++ b/include/trace/events/gfpflags.h @@ -36,6 +36,7 @@ {(unsigned long)__GFP_RECLAIMABLE, "GFP_RECLAIMABLE"}, \ {(unsigned long)__GFP_MOVABLE, "GFP_MOVABLE"}, \ {(un…
creator: Glauber Costa
date: 2012-10-16T10:16:42-00:00

[PATCH v5 06/14] memcg: kmem controller infrastructure
type: item
description: This patch introduces infrastructure for tracking kernel memory pages to a given memcg. This will happen whenever the caller includes the flag __GFP_KMEMCG flag, and the task belong to a memcg other than the root. In memcontrol.h those functions are wrapped in inline acessors. The idea is to later on, patch those with static branches, so we don't incur any overhead when no mem cgroups with limited kmem are being used. Users of this functionality shall interact with the memcg core code through the following functions: memcg_kmem_newpage_charge: will return true if the group can handle the allocation. At this point, struct page is not yet allocated. memcg_kmem_commit_charge: will either revert the charge, if struct page allocation failed, or embed memcg information into page_cgroup. memcg_kmem_uncharge_page: called at free time, will revert the charge. [ v2: improved comments and standardized function names ] [ v3: handle no longer opaque, functions not exported, even more comments ] [ v4: reworked Used bit handling and surroundings for more clarity ] [ v5: simplified code for kmemcg compiled out and core functions in memcontrol.c, moved kmem code to the middle to avoid forward decls ] Signed-off-by: Glauber Costa <glommer@parallels.com> Acked-by: Michal Hocko <mhocko@suse.cz> CC: Christoph Lameter <cl@linux.com> CC: Pekka Enberg <penberg@cs.helsinki.fi> CC: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> CC: Johannes Weiner <hannes@cmpxchg.org> CC: Tejun Heo <tj@kernel.org> --- include/linux/memcontrol.h | 98 ++++++++++++++++++++++++++ mm/memcontrol.c | 169 +++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 267 insertions(+) diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h index 8d9489f..303a456 100644 --- a/include/linux/memcontrol.h +++ b/include/linux/memcontrol.h @@ -21,6 +21,7 @@ #define _LINUX_MEMCONTROL_H #include <linux/cgroup.h> #include <linux/vm_event_item.h> +#include <linux/hardirq.h> struct mem_cgroup; struct page_cgro…
creator: Glauber Costa
date: 2012-10-16T10:16:43-00:00

[PATCH v5 07/14] mm: Allocate kernel pages to the right memcg
type: item
description: When a process tries to allocate a page with the __GFP_KMEMCG flag, the page allocator will call the corresponding memcg functions to validate the allocation. Tasks in the root memcg can always proceed. To avoid adding markers to the page - and a kmem flag that would necessarily follow, as much as doing page_cgroup lookups for no reason, whoever is marking its allocations with __GFP_KMEMCG flag is responsible for telling the page allocator that this is such an allocation at free_pages() time. This is done by the invocation of __free_accounted_pages() and free_accounted_pages(). [ v2: inverted test order to avoid a memcg_get leak, free_accounted_pages simplification ] [ v4: test for TIF_MEMDIE at newpage_charge ] Signed-off-by: Glauber Costa <glommer@parallels.com> Acked-by: Michal Hocko <mhocko@suse.cz> Acked-by: Mel Gorman <mgorman@suse.de> Acked-by: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> CC: Christoph Lameter <cl@linux.com> CC: Pekka Enberg <penberg@cs.helsinki.fi> CC: Johannes Weiner <hannes@cmpxchg.org> CC: Suleiman Souhlal <suleiman@google.com> CC: Tejun Heo <tj@kernel.org> --- include/linux/gfp.h | 3 +++ mm/page_alloc.c | 35 +++++++++++++++++++++++++++++++++++ 2 files changed, 38 insertions(+) diff --git a/include/linux/gfp.h b/include/linux/gfp.h index 9289d46..8f6fe34 100644 --- a/include/linux/gfp.h +++ b/include/linux/gfp.h @@ -362,6 +362,9 @@ extern void free_pages(unsigned long addr, unsigned int order); extern void free_hot_cold_page(struct page *page, int cold); extern void free_hot_cold_page_list(struct list_head *list, int cold); +extern void __free_accounted_pages(struct page *page, unsigned int order); +extern void free_accounted_pages(unsigned long addr, unsigned int order); + #define __free_page(page) __free_pages((page), 0) #define free_page(addr) free_pages((addr), 0) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index feddc7f..dcf33ad 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -2595,6 +2595,7 @@ __alloc_pages_nodemask(g…
creator: Glauber Costa
date: 2012-10-16T10:16:44-00:00

[PATCH v5 09/14] memcg: kmem accounting lifecycle management
type: item
description: Because kmem charges can outlive the cgroup, we need to make sure that we won't free the memcg structure while charges are still in flight. For reviewing simplicity, the charge functions will issue mem_cgroup_get() at every charge, and mem_cgroup_put() at every uncharge. This can get expensive, however, and we can do better. mem_cgroup_get() only really needs to be issued once: when the first limit is set. In the same spirit, we only need to issue mem_cgroup_put() when the last charge is gone. We'll need an extra bit in kmem_accounted for that: KMEM_ACCOUNTED_DEAD. it will be set when the cgroup dies, if there are charges in the group. If there aren't, we can proceed right away. Our uncharge function will have to test that bit every time the charges drop to 0. Because that is not the likely output of res_counter_uncharge, this should not impose a big hit on us: it is certainly much better than a reference count decrease at every operation. [ v3: merged all lifecycle related patches in one ] [ v5: changed memcg_kmem_dead's name ] Signed-off-by: Glauber Costa <glommer@parallels.com> Acked-by: Michal Hocko <mhocko@suse.cz> Acked-by: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> CC: Christoph Lameter <cl@linux.com> CC: Pekka Enberg <penberg@cs.helsinki.fi> CC: Johannes Weiner <hannes@cmpxchg.org> CC: Suleiman Souhlal <suleiman@google.com> CC: Tejun Heo <tj@kernel.org> --- mm/memcontrol.c | 56 +++++++++++++++++++++++++++++++++++++++++++++++++------- 1 file changed, 49 insertions(+), 7 deletions(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 1182188..e24b388 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -344,6 +344,7 @@ struct mem_cgroup { /* internal only representation about the status of kmem accounting. */ enum { KMEM_ACCOUNTED_ACTIVE = 0, /* accounted by this cgroup itself */ + KMEM_ACCOUNTED_DEAD, /* dead memcg, pending kmem charges */ }; #define KMEM_ACCOUNTED_MASK (1 << KMEM_ACCOUNTED_ACTIVE) @@ -353,6 +354,22 @@ static void memcg_kmem_set_ac…
creator: Glauber Costa
date: 2012-10-16T10:16:46-00:00

[PATCH v5 10/14] memcg: use static branches when code not in use
type: item
description: We can use static branches to patch the code in or out when not used. Because the _ACTIVE bit on kmem_accounted is only set after the increment is done, we guarantee that the root memcg will always be selected for kmem charges until all call sites are patched (see memcg_kmem_enabled). This guarantees that no mischarges are applied. static branch decrement happens when the last reference count from the kmem accounting in memcg dies. This will only happen when the charges drop down to 0. When that happen, we need to disable the static branch only on those memcgs that enabled it. To achieve this, we would be forced to complicate the code by keeping track of which memcgs were the ones that actually enabled limits, and which ones got it from its parents. It is a lot simpler just to do static_key_slow_inc() on every child that is accounted. [ v4: adapted this patch to the changes in kmem_accounted ] Signed-off-by: Glauber Costa <glommer@parallels.com> Acked-by: Michal Hocko <mhocko@suse.cz> Acked-by: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> CC: Christoph Lameter <cl@linux.com> CC: Pekka Enberg <penberg@cs.helsinki.fi> CC: Johannes Weiner <hannes@cmpxchg.org> CC: Suleiman Souhlal <suleiman@google.com> CC: Tejun Heo <tj@kernel.org> --- include/linux/memcontrol.h | 4 ++- mm/memcontrol.c | 79 +++++++++++++++++++++++++++++++++++++++++++--- 2 files changed, 78 insertions(+), 5 deletions(-) diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h index 303a456..34e96cf 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; @@ -401,9 +402,10 @@ struct sock; void sock_update_memcg(struct sock *sk); void sock_release_memcg(struct sock *sk); +extern struct static_key memcg_kmem_enabled_key; static inline bool memcg_kmem_enabled(void) { - return true; + return static_key_fa…
creator: Glauber Costa
date: 2012-10-16T10:16:47-00:00

[PATCH v5 11/14] memcg: allow a memcg with kmem charges to be destructed.
type: item
description: Because the ultimate goal of the kmem tracking in memcg is to track slab pages as well, we can't guarantee that we'll always be able to point a page to a particular process, and migrate the charges along with it - since in the common case, a page will contain data belonging to multiple processes. Because of that, when we destroy a memcg, we only make sure the destruction will succeed by discounting the kmem charges from the user charges when we try to empty the cgroup. Signed-off-by: Glauber Costa <glommer@parallels.com> Acked-by: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Reviewed-by: Michal Hocko <mhocko@suse.cz> CC: Christoph Lameter <cl@linux.com> CC: Pekka Enberg <penberg@cs.helsinki.fi> CC: Johannes Weiner <hannes@cmpxchg.org> CC: Suleiman Souhlal <suleiman@google.com> CC: Tejun Heo <tj@kernel.org> --- mm/memcontrol.c | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 1dd31a1..9086cf2 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -544,6 +544,11 @@ static void disarm_kmem_keys(struct mem_cgroup *memcg) { if (memcg_kmem_is_active(memcg)) static_key_slow_dec(&memcg_kmem_enabled_key); + /* + * This check can't live in kmem destruction function, + * since the charges will outlive the cgroup + */ + WARN_ON(res_counter_read_u64(&memcg->kmem, RES_USAGE) != 0); } #else static void disarm_kmem_keys(struct mem_cgroup *memcg) @@ -3993,6 +3998,7 @@ static int mem_cgroup_force_empty(struct mem_cgroup *memcg, bool free_all) int node, zid, shrink; int nr_retries = MEM_CGROUP_RECLAIM_RETRIES; struct cgroup *cgrp = memcg->css.cgroup; + u64 usage; css_get(&memcg->css); @@ -4026,8 +4032,17 @@ move_account: mem_cgroup_end_move(memcg); memcg_oom_recover(memcg); cond_resched(); + /* + * Kernel memory may not necessarily be trackable to a specific + * process. So they are not migrated, and therefore we can't + * expect their value to drop to 0 here. + * + * having res filled up with kmem only is …
creator: Glauber Costa
date: 2012-10-16T10:16:48-00:00

[PATCH v5 13/14] protect architectures where THREAD_SIZE &gt;= PAGE_SIZE against fork bombs
type: item
description: Because those architectures will draw their stacks directly from the page allocator, rather than the slab cache, we can directly pass __GFP_KMEMCG flag, and issue the corresponding free_pages. This code path is taken when the architecture doesn't define CONFIG_ARCH_THREAD_INFO_ALLOCATOR (only ia64 seems to), and has THREAD_SIZE >= PAGE_SIZE. Luckily, most - if not all - of the remaining architectures fall in this category. This will guarantee that every stack page is accounted to the memcg the process currently lives on, and will have the allocations to fail if they go over limit. For the time being, I am defining a new variant of THREADINFO_GFP, not to mess with the other path. Once the slab is also tracked by memcg, we can get rid of that flag. Tested to successfully protect against :(){ :|:& };: Signed-off-by: Glauber Costa <glommer@parallels.com> Acked-by: Frederic Weisbecker <fweisbec@redhat.com> Acked-by: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Reviewed-by: Michal Hocko <mhocko@suse.cz> CC: Christoph Lameter <cl@linux.com> CC: Pekka Enberg <penberg@cs.helsinki.fi> CC: Johannes Weiner <hannes@cmpxchg.org> CC: Suleiman Souhlal <suleiman@google.com> CC: Tejun Heo <tj@kernel.org> --- include/linux/thread_info.h | 2 ++ kernel/fork.c | 4 ++-- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/include/linux/thread_info.h b/include/linux/thread_info.h index ccc1899..e7e0473 100644 --- a/include/linux/thread_info.h +++ b/include/linux/thread_info.h @@ -61,6 +61,8 @@ extern long do_no_restart_syscall(struct restart_block *parm); # define THREADINFO_GFP (GFP_KERNEL | __GFP_NOTRACK) #endif +#define THREADINFO_GFP_ACCOUNTED (THREADINFO_GFP | __GFP_KMEMCG) + /* * flag set/clear/test wrappers * - pass TIF_xxxx constants to these functions diff --git a/kernel/fork.c b/kernel/fork.c index 03b86f1..b3f6298 100644 --- a/kernel/fork.c +++ b/kernel/fork.c @@ -146,7 +146,7 @@ void __weak arch_release_thread_info(struct thread_info *ti) static struct thread_inf…
creator: Glauber Costa
date: 2012-10-16T10:16:50-00:00

[PATCH v5 14/14] Add documentation about the kmem controller
type: item
description: Signed-off-by: Glauber Costa <glommer@parallels.com> CC: Frederic Weisbecker <fweisbec@redhat.com> CC: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> CC: Michal Hocko <mhocko@suse.cz> CC: Christoph Lameter <cl@linux.com> CC: Pekka Enberg <penberg@cs.helsinki.fi> CC: Johannes Weiner <hannes@cmpxchg.org> CC: Suleiman Souhlal <suleiman@google.com> CC: Tejun Heo <tj@kernel.org> --- Documentation/cgroups/memory.txt | 58 +++++++++++++++++++++++++++++++++++++++- 1 file changed, 57 insertions(+), 1 deletion(-) diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt index c07f7b4..dd15be8 100644 --- a/Documentation/cgroups/memory.txt +++ b/Documentation/cgroups/memory.txt @@ -71,6 +71,11 @@ Brief summary of control files. memory.oom_control # set/show oom controls. memory.numa_stat # show the number of memory usage per numa node + memory.kmem.limit_in_bytes # set/show hard limit for kernel memory + memory.kmem.usage_in_bytes # show current kernel memory allocation + memory.kmem.failcnt # show the number of kernel memory usage hits limits + memory.kmem.max_usage_in_bytes # show max kernel memory usage recorded + 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.tcp.failcnt # show the number of tcp buf memory usage hits limits @@ -268,20 +273,65 @@ the amount of kernel memory used by the system. Kernel memory is fundamentally different than user memory, since it can't be swapped out, which makes it possible to DoS the system by consuming too much of this precious resource. +Kernel memory won't be accounted at all until limit on a group is set. This +allows for existing setups to continue working without disruption. The limit +cannot be set if the cgroup have children, or if there are already tasks in the +cgroup. When use_hierarchy == 1 and a group is accounted, its children will +automatically be accounted regardless of their limit value. + +A…
creator: Glauber Costa
date: 2012-10-16T10:16:51-00:00

Re: [PATCH v5 04/14] kmem accounting basic infrastructure
type: item
description: On Tue 16-10-12 14:16:41, Glauber Costa wrote: > This patch adds the basic infrastructure for the accounting of kernel > memory. 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. > > Per cgroup kmem memory accounting is not enabled until a limit is set > for the group. Once the limit is set the accounting cannot be disabled > for that group. This means that after the patch is applied, no > behavioral changes exists for whoever is still using memcg to control > their memory usage, until memory.kmem.limit_in_bytes is set for the > first time. > > 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) > > [ v4: make kmem files part of the main array; > do not allow limit to be set for non-empty cgroups ] > [ v5: cosmetic changes ] > > Signed-off-by: Glauber Costa <glommer@parallels.com> > Acked-by: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> > CC: Michal Hocko <mhocko@suse.cz> > CC: Johannes Weiner <hannes@cmpxchg.org> > CC: Tejun Heo <tj@kernel.org> Acked-by: Michal Hocko <mhocko@suse.cz> > --- > mm/memcontrol.c | 116 +++++++++++++++++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 115 insertions(+), 1 deletion(-) > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > index 71d259e..30eafeb 100644 > --- a/mm/memcontrol.c > +++ b/mm/memcontrol.c > @@ -266,6 +266,10 @@ struct …
creator: Michal Hocko
date: 2012-10-16T12:14:58-00:00

Re: [PATCH v5 05/14] Add a __GFP_KMEMCG flag
type: item
description: On Tue 16-10-12 14:16:42, Glauber Costa wrote: > This flag is used to indicate to the callees that this allocation is a > kernel allocation in process context, and should be accounted to > current's memcg. It takes numerical place of the of the recently removed > __GFP_NO_KSWAPD. > > [ v4: make flag unconditional, also declare it in trace code ] > > Signed-off-by: Glauber Costa <glommer@parallels.com> > Acked-by: Johannes Weiner <hannes@cmpxchg.org> > Acked-by: Rik van Riel <riel@redhat.com> > Acked-by: Mel Gorman <mel@csn.ul.ie> > Acked-by: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> > CC: Christoph Lameter <cl@linux.com> > CC: Pekka Enberg <penberg@cs.helsinki.fi> > CC: Michal Hocko <mhocko@suse.cz> > CC: Suleiman Souhlal <suleiman@google.com> > CC: Tejun Heo <tj@kernel.org> I thought I have acked the patch already Acked-by: Michal Hocko <mhocko@suse.cz> > --- > include/linux/gfp.h | 3 ++- > include/trace/events/gfpflags.h | 1 + > 2 files changed, 3 insertions(+), 1 deletion(-) > > diff --git a/include/linux/gfp.h b/include/linux/gfp.h > index 02c1c97..9289d46 100644 > --- a/include/linux/gfp.h > +++ b/include/linux/gfp.h > @@ -31,6 +31,7 @@ struct vm_area_struct; > #define ___GFP_THISNODE 0x40000u > #define ___GFP_RECLAIMABLE 0x80000u > #define ___GFP_NOTRACK 0x200000u > +#define ___GFP_KMEMCG 0x400000u > #define ___GFP_OTHER_NODE 0x800000u > #define ___GFP_WRITE 0x1000000u > > @@ -87,7 +88,7 @@ struct vm_area_struct; > > #define __GFP_OTHER_NODE ((__force gfp_t)___GFP_OTHER_NODE) /* On behalf of other node */ > #define __GFP_WRITE ((__force gfp_t)___GFP_WRITE) /* Allocator intends to dirty page */ > - > +#define __GFP_KMEMCG ((__force gfp_t)___GFP_KMEMCG) /* Allocation comes from a memcg-accounted resource */ > /* > * This may seem redundant, but it's a way of annotating false positives vs. > * allocations that simply cannot be supported (e.g. page tables). > diff --git a/include/trace/events/gfpflags.h b/include/trace/events/gfpflags.h > index 9391706..7…
creator: Michal Hocko
date: 2012-10-16T12:15:58-00:00

Re: [PATCH v5 14/14] Add documentation about the kmem controller
type: item
description: On Tue 16-10-12 14:16:51, Glauber Costa wrote: > Signed-off-by: Glauber Costa <glommer@parallels.com> > CC: Frederic Weisbecker <fweisbec@redhat.com> > CC: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> > CC: Michal Hocko <mhocko@suse.cz> > CC: Christoph Lameter <cl@linux.com> > CC: Pekka Enberg <penberg@cs.helsinki.fi> > CC: Johannes Weiner <hannes@cmpxchg.org> > CC: Suleiman Souhlal <suleiman@google.com> > CC: Tejun Heo <tj@kernel.org> Acked-by: Michal Hocko <mhocko@suse.cz Just a nit.. > --- > Documentation/cgroups/memory.txt | 58 +++++++++++++++++++++++++++++++++++++++- > 1 file changed, 57 insertions(+), 1 deletion(-) > > diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt > index c07f7b4..dd15be8 100644 > --- a/Documentation/cgroups/memory.txt > +++ b/Documentation/cgroups/memory.txt [...] > @@ -268,20 +273,65 @@ the amount of kernel memory used by the system. Kernel memory is fundamentally > different than user memory, since it can't be swapped out, which makes it > possible to DoS the system by consuming too much of this precious resource. > > +Kernel memory won't be accounted at all until limit on a group is set. This > +allows for existing setups to continue working without disruption. The limit > +cannot be set if the cgroup have children, or if there are already tasks in the > +cgroup. When use_hierarchy == 1 and a group is accounted, its children will > +automatically be accounted regardless of their limit value. > + > +After a controller is first limited, it will be kept being accounted until it s/controller/group/ > +is removed. The memory limitation itself, can of course be removed by writing > +-1 to memory.kmem.limit_in_bytes. In this case, kmem will be accounted, but not > +limited. > + -- Michal Hocko SUSE Labs
creator: Michal Hocko
date: 2012-10-16T12:23:24-00:00

Re: [PATCH v5 07/14] mm: Allocate kernel pages to the right memcg
type: item
description: On Tue, 16 Oct 2012, Glauber Costa wrote: > To avoid adding markers to the page - and a kmem flag that would > necessarily follow, as much as doing page_cgroup lookups for no reason, > whoever is marking its allocations with __GFP_KMEMCG flag is responsible > for telling the page allocator that this is such an allocation at > free_pages() time. This is done by the invocation of > __free_accounted_pages() and free_accounted_pages(). Hmmm... The code paths to free pages are often shared between multiple subsystems. Are you sure that this is actually working and accurately tracks the MEMCG pages? > +/* > + * __free_accounted_pages and free_accounted_pages will free pages allocated > + * with __GFP_KMEMCG. > + * > + * Those pages are accounted to a particular memcg, embedded in the > + * corresponding page_cgroup. To avoid adding a hit in the allocator to search > + * for that information only to find out that it is NULL for users who have no > + * interest in that whatsoever, we provide these functions. > + * > + * The caller knows better which flags it relies on. > + */ > +void __free_accounted_pages(struct page *page, unsigned int order) > +{ > + memcg_kmem_uncharge_page(page, order); > + __free_pages(page, order); > +} If we already are introducing such an API: Could it not be made more general so that it can also be used in the future to communicate other characteristics of a page on free?
creator: Christoph Lameter
date: 2012-10-16T15:31:13-00:00

Re: [PATCH v5 14/14] Add documentation about the kmem controller
type: item
description: On Tue, 16 Oct 2012, Glauber Costa wrote: > > + memory.kmem.limit_in_bytes # set/show hard limit for kernel memory > + memory.kmem.usage_in_bytes # show current kernel memory allocation > + memory.kmem.failcnt # show the number of kernel memory usage hits limits > + memory.kmem.max_usage_in_bytes # show max kernel memory usage recorded Does it actually make sense to limit kernel memory? The user generally has no idea how much kernel memory a process is using and kernel changes can change the memory footprint. Given the fuzzy accounting in the kernel a large cache refill (if someone configures the slab batch count to be really big f.e.) can account a lot of memory to the wrong cgroup. The allocation could fail. Limiting the total memory use of a process (U+K) would make more sense I guess. Only U is probably sufficient? In what way would a limitation on kernel memory in use be good?
creator: Christoph Lameter
date: 2012-10-16T18:25:06-00:00

Re: [PATCH v5 07/14] mm: Allocate kernel pages to the right memcg
type: item
description: On 10/16/2012 07:31 PM, Christoph Lameter wrote: > On Tue, 16 Oct 2012, Glauber Costa wrote: > >> To avoid adding markers to the page - and a kmem flag that would >> necessarily follow, as much as doing page_cgroup lookups for no reason, >> whoever is marking its allocations with __GFP_KMEMCG flag is responsible >> for telling the page allocator that this is such an allocation at >> free_pages() time. This is done by the invocation of >> __free_accounted_pages() and free_accounted_pages(). > > Hmmm... The code paths to free pages are often shared between multiple > subsystems. Are you sure that this is actually working and accurately > tracks the MEMCG pages? > As described above, only call sites that are switched to free_accounted_pages are affected. There are very few of them. The stack case is particularly easy to test: every time a process appears, usage is increased in 8k. Every time a process dies, usage decreases by 8k. In my other patchseries, I include the object allocators into this. So again: there are very few call sites actually being patched. >> +/* >> + * __free_accounted_pages and free_accounted_pages will free pages allocated >> + * with __GFP_KMEMCG. >> + * >> + * Those pages are accounted to a particular memcg, embedded in the >> + * corresponding page_cgroup. To avoid adding a hit in the allocator to search >> + * for that information only to find out that it is NULL for users who have no >> + * interest in that whatsoever, we provide these functions. >> + * >> + * The caller knows better which flags it relies on. >> + */ >> +void __free_accounted_pages(struct page *page, unsigned int order) >> +{ >> + memcg_kmem_uncharge_page(page, order); >> + __free_pages(page, order); >> +} > > If we already are introducing such an API: Could it not be made more > general so that it can also be used in the future to communicate other > characteristics of a page on free? > I guess so. Which other use case do you have in mind? In any case, I don't see this as a…
creator: Glauber Costa
date: 2012-10-16T18:55:30-00:00

Re: [PATCH v5 14/14] Add documentation about the kmem controller
type: item
description: On 10/16/2012 10:25 PM, Christoph Lameter wrote: > On Tue, 16 Oct 2012, Glauber Costa wrote: > >> >> + memory.kmem.limit_in_bytes # set/show hard limit for kernel memory >> + memory.kmem.usage_in_bytes # show current kernel memory allocation >> + memory.kmem.failcnt # show the number of kernel memory usage hits limits >> + memory.kmem.max_usage_in_bytes # show max kernel memory usage recorded > > Does it actually make sense to limit kernel memory? Yes. > The user generally has > no idea how much kernel memory a process is using and kernel changes can > change the memory footprint. Given the fuzzy accounting in the kernel a > large cache refill (if someone configures the slab batch count to be > really big f.e.) can account a lot of memory to the wrong cgroup. The > allocation could fail. > It heavily depends on the type of the user. The user may not know how much kernel memory precisely will be used, but he/she usually knows quite well that it shouldn't be all cgroups together shouldn't use more than available in the system. IOW: It is usually safe to overcommit user memory, but not kernel memory. This is absolutely crucial in any high-density container host, and we've been doing this in OpenVZ for ages (in an uglier form than this) > Limiting the total memory use of a process (U+K) would make more sense I > guess. Only U is probably sufficient? In what way would a limitation on > kernel memory in use be good? > The kmem counter is also fed into the u counter. If the limit value of "u" is equal or greater than "k", this is actually what you are doing. For a lot of application yes, only U is sufficient. This is the default, btw, since "k" is only even accounted if you set the limit. All those use cases are detailed a bit below in this file. A limitation of kernel memory use would be good, for example, to prevent abuse from non-trusted containers in a high density, shared, container environment.
creator: Glauber Costa
date: 2012-10-16T19:02:46-00:00

Re: [PATCH v5 14/14] Add documentation about the kmem controller
type: item
description: On Tue, 16 Oct 2012, Glauber Costa wrote: > A limitation of kernel memory use would be good, for example, to prevent > abuse from non-trusted containers in a high density, shared, container > environment. But that would be against intentional abuse by someone who has code that causes the kernel to use a lot of memory on its behalf. We already need protection from that without memcg.
creator: Christoph Lameter
date: 2012-10-16T19:30:23-00:00

Re: [PATCH v5 06/14] memcg: kmem controller infrastructure
type: item
description: (2012/10/16 19:16), Glauber Costa wrote: > This patch introduces infrastructure for tracking kernel memory pages to > a given memcg. This will happen whenever the caller includes the flag > __GFP_KMEMCG flag, and the task belong to a memcg other than the root. > > In memcontrol.h those functions are wrapped in inline acessors. The > idea is to later on, patch those with static branches, so we don't incur > any overhead when no mem cgroups with limited kmem are being used. > > Users of this functionality shall interact with the memcg core code > through the following functions: > > memcg_kmem_newpage_charge: will return true if the group can handle the > allocation. At this point, struct page is not > yet allocated. > > memcg_kmem_commit_charge: will either revert the charge, if struct page > allocation failed, or embed memcg information > into page_cgroup. > > memcg_kmem_uncharge_page: called at free time, will revert the charge. > > [ v2: improved comments and standardized function names ] > [ v3: handle no longer opaque, functions not exported, > even more comments ] > [ v4: reworked Used bit handling and surroundings for more clarity ] > [ v5: simplified code for kmemcg compiled out and core functions in > memcontrol.c, moved kmem code to the middle to avoid forward decls ] > > Signed-off-by: Glauber Costa <glommer@parallels.com> > Acked-by: Michal Hocko <mhocko@suse.cz> > CC: Christoph Lameter <cl@linux.com> > CC: Pekka Enberg <penberg@cs.helsinki.fi> > CC: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> > CC: Johannes Weiner <hannes@cmpxchg.org> > CC: Tejun Heo <tj@kernel.org> Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
creator: KAMEZAWA Hiroyuki
date: 2012-10-17T06:40:46-00:00

Re: [PATCH v5 03/14] memcg: change defines to an enum
type: item
description: On Tue, 16 Oct 2012, Glauber Costa wrote: > 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. > > [ v2: use named enum as type throughout the file as well ] > > Signed-off-by: Glauber Costa <glommer@parallels.com> > Acked-by: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> > Acked-by: Michal Hocko <mhocko@suse.cz> > Acked-by: Johannes Weiner <hannes@cmpxchg.org> > CC: Tejun Heo <tj@kernel.org> Acked-by: David Rientjes <rientjes@google.com>
creator: David Rientjes
date: 2012-10-17T21:50:17-00:00

Re: [PATCH v5 04/14] kmem accounting basic infrastructure
type: item
description: On Tue, 16 Oct 2012, Glauber Costa wrote: > This patch adds the basic infrastructure for the accounting of kernel > memory. 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. > > Per cgroup kmem memory accounting is not enabled until a limit is set > for the group. Once the limit is set the accounting cannot be disabled > for that group. This means that after the patch is applied, no > behavioral changes exists for whoever is still using memcg to control > their memory usage, until memory.kmem.limit_in_bytes is set for the > first time. > > 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) > > [ v4: make kmem files part of the main array; > do not allow limit to be set for non-empty cgroups ] > [ v5: cosmetic changes ] > > Signed-off-by: Glauber Costa <glommer@parallels.com> > Acked-by: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> > CC: Michal Hocko <mhocko@suse.cz> > CC: Johannes Weiner <hannes@cmpxchg.org> > CC: Tejun Heo <tj@kernel.org> > --- > mm/memcontrol.c | 116 +++++++++++++++++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 115 insertions(+), 1 deletion(-) > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > index 71d259e..30eafeb 100644 > --- a/mm/memcontrol.c > +++ b/mm/memcontrol.c > @@ -266,6 +266,10 @@ struct mem_cgroup { > }; > > /* > + * the counter to…
creator: David Rientjes
date: 2012-10-17T22:08:04-00:00

Re: [PATCH v5 05/14] Add a __GFP_KMEMCG flag
type: item
description: On Tue, 16 Oct 2012, Glauber Costa wrote: > This flag is used to indicate to the callees that this allocation is a > kernel allocation in process context, and should be accounted to > current's memcg. It takes numerical place of the of the recently removed > __GFP_NO_KSWAPD. > > [ v4: make flag unconditional, also declare it in trace code ] > > Signed-off-by: Glauber Costa <glommer@parallels.com> > Acked-by: Johannes Weiner <hannes@cmpxchg.org> > Acked-by: Rik van Riel <riel@redhat.com> > Acked-by: Mel Gorman <mel@csn.ul.ie> > Acked-by: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> > CC: Christoph Lameter <cl@linux.com> > CC: Pekka Enberg <penberg@cs.helsinki.fi> > CC: Michal Hocko <mhocko@suse.cz> > CC: Suleiman Souhlal <suleiman@google.com> > CC: Tejun Heo <tj@kernel.org> Acked-by: David Rientjes <rientjes@google.com>
creator: David Rientjes
date: 2012-10-17T22:09:04-00:00

Re: [PATCH v5 00/14] kmem controller for memcg.
type: item
description: On Tue, 16 Oct 2012 14:16:37 +0400 Glauber Costa <glommer@parallels.com> wrote: > ... > > A general explanation of what this is all about follows: > > The kernel memory limitation mechanism for memcg concerns itself with > disallowing potentially non-reclaimable allocations to happen in exaggerate > quantities by a particular set of processes (cgroup). Those allocations could > create pressure that affects the behavior of a different and unrelated set of > processes. > > Its basic working mechanism is to annotate some allocations with the > _GFP_KMEMCG flag. When this flag is set, the current process allocating will > have its memcg identified and charged against. When reaching a specific limit, > further allocations will be denied. The need to set _GFP_KMEMCG is rather unpleasing, and makes one wonder "why didn't it just track all allocations". Does this mean that over time we can expect more sites to get the _GFP_KMEMCG tagging? If so, are there any special implications, or do we just go in, do the one-line patch and expect everything to work? If so, why don't we go in and do that tagging right now? And how *accurate* is the proposed code? What percentage of kernel memory allocations are unaccounted, typical case and worst case? All sorts of questions come to mind over this decision, but it was unexplained. It should be, please. A lot! > > ... > > Limits lower than > the user limit effectively means there is a separate kernel memory limit that > may be reached independently than the user limit. Values equal or greater than > the user limit implies only that kernel memory is tracked. This provides a > unified vision of "maximum memory", be it kernel or user memory. > I'm struggling to understand that text much at all. Reading the Documentation/cgroups/memory.txt patch helped.
creator: akpm
date: 2012-10-17T22:11:42-00:00

Re: [PATCH v5 01/14] memcg: Make it possible to use the stock for more than one page.
type: item
description: On Tue, 16 Oct 2012 14:16:38 +0400 Glauber Costa <glommer@parallels.com> wrote: > From: Suleiman Souhlal <ssouhlal@FreeBSD.org> > > We currently have a percpu stock cache scheme that charges one page at a > time from memcg->res, the user counter. When the kernel memory > controller comes into play, we'll need to charge more than that. > > This is because kernel memory allocations will also draw from the user > counter, and can be bigger than a single page, as it is the case with > the stack (usually 2 pages) or some higher order slabs. > > ... > > -/* > - * 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. > +/** > + * consume_stock: Try to consume stocked charge on this cpu. > + * @memcg: memcg to consume from. > + * @nr_pages: how many pages to charge. > + * > + * The charges will only happen if @memcg matches the current cpu's memcg > + * stock, and at least @nr_pages are available in that stock. Failure to > + * service an allocation will refill the stock. > + * > + * returns true if succesfull, false otherwise. spello. > */ > -static bool consume_stock(struct mem_cgroup *memcg) > +static bool consume_stock(struct mem_cgroup *memcg, int nr_pages) I don't believe there is a case for nr_pages < 0 here? If not then I suggest that it would be clearer to use an unsigned type, like memcg_stock_pcp.stock. > > ... >
creator: akpm
date: 2012-10-17T22:11:55-00:00

Re: [PATCH v5 04/14] kmem accounting basic infrastructure
type: item
description: On Tue, 16 Oct 2012 14:16:41 +0400 Glauber Costa <glommer@parallels.com> wrote: > This patch adds the basic infrastructure for the accounting of kernel > memory. To control that, the following files are created: > > * memory.kmem.usage_in_bytes > * memory.kmem.limit_in_bytes > * memory.kmem.failcnt gargh. "failcnt" is not a word. Who was it who first thought that omitting voewls from words improves anything? Sigh. That pooch is already screwed and there's nothing we can do about it now. > * 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. > > Per cgroup kmem memory accounting is not enabled until a limit is set > for the group. Once the limit is set the accounting cannot be disabled > for that group. This means that after the patch is applied, no > behavioral changes exists for whoever is still using memcg to control > their memory usage, until memory.kmem.limit_in_bytes is set for the > first time. > > 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) > > > ... > > +/* internal only representation about the status of kmem accounting. */ > +enum { > + KMEM_ACCOUNTED_ACTIVE = 0, /* accounted by this cgroup itself */ > +}; > + > +#define KMEM_ACCOUNTED_MASK (1 << KMEM_ACCOUNTED_ACTIVE) > + > +#ifdef CONFIG_MEMCG_KMEM > +static void memcg_kmem_set_active(struct mem_cgroup *memcg) > +{ > + set_bit(KMEM_ACCOUNTED_ACTIVE, &memcg->kmem_accounted); > +} > +#endif I don't think memcg_kmem_set_active() really needs to exist. It ha…
creator: akpm
date: 2012-10-17T22:12:07-00:00

Re: [PATCH v5 06/14] memcg: kmem controller infrastructure
type: item
description: On Tue, 16 Oct 2012 14:16:43 +0400 Glauber Costa <glommer@parallels.com> wrote: > This patch introduces infrastructure for tracking kernel memory pages to > a given memcg. This will happen whenever the caller includes the flag > __GFP_KMEMCG flag, and the task belong to a memcg other than the root. > > In memcontrol.h those functions are wrapped in inline acessors. The > idea is to later on, patch those with static branches, so we don't incur > any overhead when no mem cgroups with limited kmem are being used. > > Users of this functionality shall interact with the memcg core code > through the following functions: > > memcg_kmem_newpage_charge: will return true if the group can handle the > allocation. At this point, struct page is not > yet allocated. > > memcg_kmem_commit_charge: will either revert the charge, if struct page > allocation failed, or embed memcg information > into page_cgroup. > > memcg_kmem_uncharge_page: called at free time, will revert the charge. > > ... > > +static __always_inline bool > +memcg_kmem_newpage_charge(gfp_t gfp, struct mem_cgroup **memcg, int order) > +{ > + if (!memcg_kmem_enabled()) > + return true; > + > + /* > + * __GFP_NOFAIL allocations will move on even if charging is not > + * possible. Therefore we don't even try, and have this allocation > + * unaccounted. We could in theory charge it with > + * res_counter_charge_nofail, but we hope those allocations are rare, > + * and won't be worth the trouble. > + */ > + if (!(gfp & __GFP_KMEMCG) || (gfp & __GFP_NOFAIL)) > + return true; > + if (in_interrupt() || (!current->mm) || (current->flags & PF_KTHREAD)) > + return true; > + > + /* If the test is dying, just let it go. */ > + if (unlikely(test_thread_flag(TIF_MEMDIE) > + || fatal_signal_pending(current))) > + return true; > + > + return __memcg_kmem_newpage_charge(gfp, memcg, order); > +} That's a big function! Why was it __always_inline? I'd have thought it would be better to move the code after memcg_kmem_enabled() out of l…
creator: akpm
date: 2012-10-17T22:12:14-00:00

Re: [PATCH v5 07/14] mm: Allocate kernel pages to the right memcg
type: item
description: On Tue, 16 Oct 2012 14:16:44 +0400 Glauber Costa <glommer@parallels.com> wrote: > When a process tries to allocate a page with the __GFP_KMEMCG flag, the > page allocator will call the corresponding memcg functions to validate > the allocation. Tasks in the root memcg can always proceed. > > To avoid adding markers to the page - and a kmem flag that would > necessarily follow, as much as doing page_cgroup lookups for no reason, > whoever is marking its allocations with __GFP_KMEMCG flag is responsible > for telling the page allocator that this is such an allocation at > free_pages() time. Well, why? Was that the correct decision? > This is done by the invocation of > __free_accounted_pages() and free_accounted_pages(). These are very general-sounding names. I'd expect the identifiers to contain "memcg" and/or "kmem", to identify what's going on.
creator: akpm
date: 2012-10-17T22:12:21-00:00

Re: [PATCH v5 11/14] memcg: allow a memcg with kmem charges to be destructed.
type: item
description: On Tue, 16 Oct 2012 14:16:48 +0400 Glauber Costa <glommer@parallels.com> wrote: > Because the ultimate goal of the kmem tracking in memcg is to track slab > pages as well, It is? For a major patchset such as this, it's pretty important to discuss such long-term plans in the top-level discussion. Covering things such as expected complexity, expected performance hit, how these plans affected the current implementation, etc. The main reason for this is that if the future plans appear to be of doubtful feasibility and the current implementation isn't sufficiently useful without the future stuff, we shouldn't merge the current implementation. It's a big issue! > we can't guarantee that we'll always be able to point a > page to a particular process, and migrate the charges along with it - > since in the common case, a page will contain data belonging to multiple > processes. > > Because of that, when we destroy a memcg, we only make sure the > destruction will succeed by discounting the kmem charges from the user > charges when we try to empty the cgroup. > > ... >
creator: akpm
date: 2012-10-17T22:12:35-00:00

Re: [PATCH v5 13/14] protect architectures where THREAD_SIZE &gt;= PAGE_SIZE against fork bombs
type: item
description: On Tue, 16 Oct 2012 14:16:50 +0400 Glauber Costa <glommer@parallels.com> wrote: > @@ -146,7 +146,7 @@ void __weak arch_release_thread_info(struct thread_info *ti) > static struct thread_info *alloc_thread_info_node(struct task_struct *tsk, > int node) > { > - struct page *page = alloc_pages_node(node, THREADINFO_GFP, > + struct page *page = alloc_pages_node(node, THREADINFO_GFP_ACCOUNTED, > THREAD_SIZE_ORDER); yay, we actually used all this code for something ;) I don't think we really saw a comprehensive list of what else the kmem controller will be used for, but I believe that all other envisaged applications will require slab accounting, yes? So it appears that all we have at present is a yet-another-fork-bomb-preventer, but one which requires that the culprit be in a container? That's reasonable, given your hosted-environment scenario. It's unclear (to me) that we should merge all this code for only this feature. Again, it would be good to have a clear listing of and plan for other applications of this code.
creator: akpm
date: 2012-10-17T22:12:45-00:00

Re: [PATCH v5 14/14] Add documentation about the kmem controller
type: item
description: On Tue, 16 Oct 2012 14:16:51 +0400 Glauber Costa <glommer@parallels.com> wrote: > +Kernel memory won't be accounted at all until limit on a group is set. This > +allows for existing setups to continue working without disruption. The limit > +cannot be set if the cgroup have children, or if there are already tasks in the > +cgroup. What behaviour will usersapce see if "The limit cannot be set"? write() returns -EINVAL, something like that?
creator: akpm
date: 2012-10-17T22:12:54-00:00

Re: [PATCH v5 06/14] memcg: kmem controller infrastructure
type: item
description: On Tue, 16 Oct 2012, Glauber Costa wrote: > diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h > index 8d9489f..303a456 100644 > --- a/include/linux/memcontrol.h > +++ b/include/linux/memcontrol.h > @@ -21,6 +21,7 @@ > #define _LINUX_MEMCONTROL_H > #include <linux/cgroup.h> > #include <linux/vm_event_item.h> > +#include <linux/hardirq.h> > > struct mem_cgroup; > struct page_cgroup; > @@ -399,6 +400,88 @@ struct sock; > #ifdef CONFIG_MEMCG_KMEM > void sock_update_memcg(struct sock *sk); > void sock_release_memcg(struct sock *sk); > + > +static inline bool memcg_kmem_enabled(void) > +{ > + return true; > +} > + > +bool __memcg_kmem_newpage_charge(gfp_t gfp, struct mem_cgroup **memcg, > + int order); > +void __memcg_kmem_commit_charge(struct page *page, > + struct mem_cgroup *memcg, int order); > +void __memcg_kmem_uncharge_page(struct page *page, int order); > + > +/** > + * memcg_kmem_newpage_charge: verify if a new kmem allocation is allowed. > + * @gfp: the gfp allocation flags. > + * @memcg: a pointer to the memcg this was charged against. > + * @order: allocation order. > + * > + * returns true if the memcg where the current task belongs can hold this > + * allocation. > + * > + * We return true automatically if this allocation is not to be accounted to > + * any memcg. > + */ > +static __always_inline bool > +memcg_kmem_newpage_charge(gfp_t gfp, struct mem_cgroup **memcg, int order) > +{ > + if (!memcg_kmem_enabled()) > + return true; > + > + /* > + * __GFP_NOFAIL allocations will move on even if charging is not > + * possible. Therefore we don't even try, and have this allocation > + * unaccounted. We could in theory charge it with > + * res_counter_charge_nofail, but we hope those allocations are rare, > + * and won't be worth the trouble. > + */ > + if (!(gfp & __GFP_KMEMCG) || (gfp & __GFP_NOFAIL)) > + return true; > + if (in_interrupt() || (!current->mm) || (current->flags & PF_KTHREAD)) > + return true; > + > + /* If the test is dying, ju…
creator: David Rientjes
date: 2012-10-17T22:37:32-00:00

Re: [PATCH v5 07/14] mm: Allocate kernel pages to the right memcg
type: item
description: On Tue, 16 Oct 2012, Glauber Costa wrote: > When a process tries to allocate a page with the __GFP_KMEMCG flag, the > page allocator will call the corresponding memcg functions to validate > the allocation. Tasks in the root memcg can always proceed. > > To avoid adding markers to the page - and a kmem flag that would > necessarily follow, as much as doing page_cgroup lookups for no reason, > whoever is marking its allocations with __GFP_KMEMCG flag is responsible > for telling the page allocator that this is such an allocation at > free_pages() time. This is done by the invocation of > __free_accounted_pages() and free_accounted_pages(). > > [ v2: inverted test order to avoid a memcg_get leak, > free_accounted_pages simplification ] > [ v4: test for TIF_MEMDIE at newpage_charge ] > > Signed-off-by: Glauber Costa <glommer@parallels.com> > Acked-by: Michal Hocko <mhocko@suse.cz> > Acked-by: Mel Gorman <mgorman@suse.de> > Acked-by: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> > CC: Christoph Lameter <cl@linux.com> > CC: Pekka Enberg <penberg@cs.helsinki.fi> > CC: Johannes Weiner <hannes@cmpxchg.org> > CC: Suleiman Souhlal <suleiman@google.com> > CC: Tejun Heo <tj@kernel.org> Acked-by: David Rientjes <rientjes@google.com>
creator: David Rientjes
date: 2012-10-17T22:43:23-00:00

Re: [PATCH v5 09/14] memcg: kmem accounting lifecycle management
type: item
description: On Tue, 16 Oct 2012, Glauber Costa wrote: > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > index 1182188..e24b388 100644 > --- a/mm/memcontrol.c > +++ b/mm/memcontrol.c > @@ -344,6 +344,7 @@ struct mem_cgroup { > /* internal only representation about the status of kmem accounting. */ > enum { > KMEM_ACCOUNTED_ACTIVE = 0, /* accounted by this cgroup itself */ > + KMEM_ACCOUNTED_DEAD, /* dead memcg, pending kmem charges */ "dead memcg with pending kmem charges" seems better. > }; > > #define KMEM_ACCOUNTED_MASK (1 << KMEM_ACCOUNTED_ACTIVE) > @@ -353,6 +354,22 @@ static void memcg_kmem_set_active(struct mem_cgroup *memcg) > { > set_bit(KMEM_ACCOUNTED_ACTIVE, &memcg->kmem_accounted); > } > + > +static bool memcg_kmem_is_active(struct mem_cgroup *memcg) > +{ > + return test_bit(KMEM_ACCOUNTED_ACTIVE, &memcg->kmem_accounted); > +} I think all of these should be inline. > + > +static void memcg_kmem_mark_dead(struct mem_cgroup *memcg) > +{ > + if (test_bit(KMEM_ACCOUNTED_ACTIVE, &memcg->kmem_accounted)) > + set_bit(KMEM_ACCOUNTED_DEAD, &memcg->kmem_accounted); > +} The set_bit() doesn't happen atomically with the test_bit(), what synchronization is required for this?
creator: David Rientjes
date: 2012-10-17T23:28:38-00:00

Re: [PATCH v5 09/14] memcg: kmem accounting lifecycle management
type: item
description: On Wed 17-10-12 16:28:38, David Rientjes wrote: > On Tue, 16 Oct 2012, Glauber Costa wrote: [...] > > + > > +static void memcg_kmem_mark_dead(struct mem_cgroup *memcg) > > +{ > > + if (test_bit(KMEM_ACCOUNTED_ACTIVE, &memcg->kmem_accounted)) > > + set_bit(KMEM_ACCOUNTED_DEAD, &memcg->kmem_accounted); > > +} > > The set_bit() doesn't happen atomically with the test_bit(), what > synchronization is required for this? The group has to be active in order to become dead so the ordering is natural and you do not need to test&set atomicaly. Also once a group becomes active it is always marked that way until it goes away. -- Michal Hocko SUSE Labs
creator: Michal Hocko
date: 2012-10-18T06:14:51-00:00

Re: [PATCH v5 00/14] kmem controller for memcg.
type: item
description: On 10/18/2012 02:11 AM, Andrew Morton wrote: > On Tue, 16 Oct 2012 14:16:37 +0400 > Glauber Costa <glommer@parallels.com> wrote: > >> ... >> >> A general explanation of what this is all about follows: >> >> The kernel memory limitation mechanism for memcg concerns itself with >> disallowing potentially non-reclaimable allocations to happen in exaggerate >> quantities by a particular set of processes (cgroup). Those allocations could >> create pressure that affects the behavior of a different and unrelated set of >> processes. >> >> Its basic working mechanism is to annotate some allocations with the >> _GFP_KMEMCG flag. When this flag is set, the current process allocating will >> have its memcg identified and charged against. When reaching a specific limit, >> further allocations will be denied. > > The need to set _GFP_KMEMCG is rather unpleasing, and makes one wonder > "why didn't it just track all allocations". > This was raised as well by Peter Zijlstra during the memcg summit. The answer I gave to him still stands: There is a cost associated with it. We believe it comes down to a trade off situation. How much tracking a particular kind of allocation help vs how much does it cost. The free path is specially more expensive, since it will always incur in a page_cgroup lookup. > Does this mean that over time we can expect more sites to get the > _GFP_KMEMCG tagging? We have being doing kernel memory limitation for OpenVZ for a lot of times, using a quite different mechanism. What we do in this work (with slab included), allows us to achieve feature parity with that. It means it is good enough for production environments. Whether or not more people will want other allocations to be tracked, I can't predict. What I do can say is that stack + slab is a very significant part of the memory one potentially cares about, and if anyone else ever have the need for more, it will come down to a trade-off calculation. > If so, are there any special implications, or do > we jus…
creator: Glauber Costa
date: 2012-10-18T08:52:14-00:00

Re: [PATCH v5 01/14] memcg: Make it possible to use the stock for more than one page.
type: item
description: On 10/18/2012 02:11 AM, Andrew Morton wrote: > On Tue, 16 Oct 2012 14:16:38 +0400 > Glauber Costa <glommer@parallels.com> wrote: > >> From: Suleiman Souhlal <ssouhlal@FreeBSD.org> >> >> We currently have a percpu stock cache scheme that charges one page at a >> time from memcg->res, the user counter. When the kernel memory >> controller comes into play, we'll need to charge more than that. >> >> This is because kernel memory allocations will also draw from the user >> counter, and can be bigger than a single page, as it is the case with >> the stack (usually 2 pages) or some higher order slabs. >> >> ... >> >> -/* >> - * 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. >> +/** >> + * consume_stock: Try to consume stocked charge on this cpu. >> + * @memcg: memcg to consume from. >> + * @nr_pages: how many pages to charge. >> + * >> + * The charges will only happen if @memcg matches the current cpu's memcg >> + * stock, and at least @nr_pages are available in that stock. Failure to >> + * service an allocation will refill the stock. >> + * >> + * returns true if succesfull, false otherwise. > > spello. > Thanks. I can never successfuly write successfull =( >> */ >> -static bool consume_stock(struct mem_cgroup *memcg) >> +static bool consume_stock(struct mem_cgroup *memcg, int nr_pages) > > I don't believe there is a case for nr_pages < 0 here? If not then I > suggest that it would be clearer to use an unsigned type, like > memcg_stock_pcp.stock. > Done, thanks.
creator: Glauber Costa
date: 2012-10-18T08:55:32-00:00

Re: [PATCH v5 04/14] kmem accounting basic infrastructure
type: item
description: On 10/18/2012 02:08 AM, David Rientjes wrote: > On Tue, 16 Oct 2012, Glauber Costa wrote: > >> This patch adds the basic infrastructure for the accounting of kernel >> memory. 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. >> >> Per cgroup kmem memory accounting is not enabled until a limit is set >> for the group. Once the limit is set the accounting cannot be disabled >> for that group. This means that after the patch is applied, no >> behavioral changes exists for whoever is still using memcg to control >> their memory usage, until memory.kmem.limit_in_bytes is set for the >> first time. >> >> 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) >> >> [ v4: make kmem files part of the main array; >> do not allow limit to be set for non-empty cgroups ] >> [ v5: cosmetic changes ] >> >> Signed-off-by: Glauber Costa <glommer@parallels.com> >> Acked-by: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> >> CC: Michal Hocko <mhocko@suse.cz> >> CC: Johannes Weiner <hannes@cmpxchg.org> >> CC: Tejun Heo <tj@kernel.org> >> --- >> mm/memcontrol.c | 116 +++++++++++++++++++++++++++++++++++++++++++++++++++++++- >> 1 file changed, 115 insertions(+), 1 deletion(-) >> >> diff --git a/mm/memcontrol.c b/mm/memcontrol.c >> index 71d259e..30eafeb 100644 >> --- a/mm/memcontrol.c >> ++…
creator: Glauber Costa
date: 2012-10-18T09:02:50-00:00

Re: [PATCH v5 04/14] kmem accounting basic infrastructure
type: item
description: On 10/18/2012 02:12 AM, Andrew Morton wrote: > On Tue, 16 Oct 2012 14:16:41 +0400 > Glauber Costa <glommer@parallels.com> wrote: > >> This patch adds the basic infrastructure for the accounting of kernel >> memory. To control that, the following files are created: >> >> * memory.kmem.usage_in_bytes >> * memory.kmem.limit_in_bytes >> * memory.kmem.failcnt > > gargh. "failcnt" is not a word. Who was it who first thought that > omitting voewls from words improves anything? > > Sigh. That pooch is already screwed and there's nothing we can do > about it now. > Dunno =( >> * 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. >> >> Per cgroup kmem memory accounting is not enabled until a limit is set >> for the group. Once the limit is set the accounting cannot be disabled >> for that group. This means that after the patch is applied, no >> behavioral changes exists for whoever is still using memcg to control >> their memory usage, until memory.kmem.limit_in_bytes is set for the >> first time. >> >> 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) >> >> >> ... >> >> +/* internal only representation about the status of kmem accounting. */ >> +enum { >> + KMEM_ACCOUNTED_ACTIVE = 0, /* accounted by this cgroup itself */ >> +}; >> + >> +#define KMEM_ACCOUNTED_MASK (1 << KMEM_ACCOUNTED_ACTIVE) >> + >> +#ifdef CONFIG_MEMCG_KMEM >> +static void memcg_kmem_set_active(struct mem_cgroup *memcg) >> +{ >> + set_bit(KMEM_ACCOUNTE…
creator: Glauber Costa
date: 2012-10-18T09:04:25-00:00

Re: [PATCH v5 06/14] memcg: kmem controller infrastructure
type: item
description: On 10/18/2012 02:12 AM, Andrew Morton wrote: > On Tue, 16 Oct 2012 14:16:43 +0400 > Glauber Costa <glommer@parallels.com> wrote: > >> This patch introduces infrastructure for tracking kernel memory pages to >> a given memcg. This will happen whenever the caller includes the flag >> __GFP_KMEMCG flag, and the task belong to a memcg other than the root. >> >> In memcontrol.h those functions are wrapped in inline acessors. The >> idea is to later on, patch those with static branches, so we don't incur >> any overhead when no mem cgroups with limited kmem are being used. >> >> Users of this functionality shall interact with the memcg core code >> through the following functions: >> >> memcg_kmem_newpage_charge: will return true if the group can handle the >> allocation. At this point, struct page is not >> yet allocated. >> >> memcg_kmem_commit_charge: will either revert the charge, if struct page >> allocation failed, or embed memcg information >> into page_cgroup. >> >> memcg_kmem_uncharge_page: called at free time, will revert the charge. >> >> ... >> >> +static __always_inline bool >> +memcg_kmem_newpage_charge(gfp_t gfp, struct mem_cgroup **memcg, int order) >> +{ >> + if (!memcg_kmem_enabled()) >> + return true; >> + >> + /* >> + * __GFP_NOFAIL allocations will move on even if charging is not >> + * possible. Therefore we don't even try, and have this allocation >> + * unaccounted. We could in theory charge it with >> + * res_counter_charge_nofail, but we hope those allocations are rare, >> + * and won't be worth the trouble. >> + */ >> + if (!(gfp & __GFP_KMEMCG) || (gfp & __GFP_NOFAIL)) >> + return true; >> + if (in_interrupt() || (!current->mm) || (current->flags & PF_KTHREAD)) >> + return true; >> + >> + /* If the test is dying, just let it go. */ >> + if (unlikely(test_thread_flag(TIF_MEMDIE) >> + || fatal_signal_pending(current))) >> + return true; >> + >> + return __memcg_kmem_newpage_charge(gfp, memcg, order); >> +} > > That's a big function! Why was it __…
creator: Glauber Costa
date: 2012-10-18T09:16:19-00:00

Re: [PATCH v5 06/14] memcg: kmem controller infrastructure
type: item
description: On 10/18/2012 02:37 AM, David Rientjes wrote: > On Tue, 16 Oct 2012, Glauber Costa wrote: > >> + /* If the test is dying, just let it go. */ >> + if (unlikely(test_thread_flag(TIF_MEMDIE) >> + || fatal_signal_pending(current))) >> + return true; > > This can be simplified to just check fatal_signal_pending(), all threads > with TIF_MEMDIE also have a pending SIGKILL. Yes, I believe it is better. I will change. >> + >> + return __memcg_kmem_newpage_charge(gfp, memcg, order); >> +} >> + >> +/** >> + * memcg_kmem_uncharge_page: uncharge pages from memcg > > Should be memcg_kmem_uncharge_pages() since it takes an order argument? > I tried to use naming as close as possible to user-memcg. But to be fair, their are always calling it page-by-page, so pages() won't be a problem here. >> + * @page: pointer to struct page being freed >> + * @order: allocation order. >> + * >> + * there is no need to specify memcg here, since it is embedded in page_cgroup >> + */ >> +static __always_inline void >> +memcg_kmem_uncharge_page(struct page *page, int order) >> +{ >> + if (memcg_kmem_enabled()) >> + __memcg_kmem_uncharge_page(page, order); >> +} >> + >> +/** >> + * memcg_kmem_commit_charge: embeds correct memcg in a page >> + * @page: pointer to struct page recently allocated >> + * @memcg: the memcg structure we charged against >> + * @order: allocation order. >> + * >> + * Needs to be called after memcg_kmem_newpage_charge, regardless of success or >> + * failure of the allocation. if @page is NULL, this function will revert the >> + * charges. Otherwise, it will commit the memcg given by @memcg to the >> + * corresponding page_cgroup. >> + */ >> +static __always_inline void >> +memcg_kmem_commit_charge(struct page *page, struct mem_cgroup *memcg, int order) >> +{ >> + if (memcg_kmem_enabled() && memcg) >> + __memcg_kmem_commit_charge(page, memcg, order); >> +} >> + >> #else >> static inline void sock_update_memcg(struct sock *sk) >> { >> @@ -406,6 +489,21 @@ static inline void so…
creator: Glauber Costa
date: 2012-10-18T09:23:28-00:00

Re: [PATCH v5 07/14] mm: Allocate kernel pages to the right memcg
type: item
description: On 10/18/2012 02:12 AM, Andrew Morton wrote: > On Tue, 16 Oct 2012 14:16:44 +0400 > Glauber Costa <glommer@parallels.com> wrote: > >> When a process tries to allocate a page with the __GFP_KMEMCG flag, the >> page allocator will call the corresponding memcg functions to validate >> the allocation. Tasks in the root memcg can always proceed. >> >> To avoid adding markers to the page - and a kmem flag that would >> necessarily follow, as much as doing page_cgroup lookups for no reason, >> whoever is marking its allocations with __GFP_KMEMCG flag is responsible >> for telling the page allocator that this is such an allocation at >> free_pages() time. > > Well, why? Was that the correct decision? > I don't fully understand your question. Is this the same question you posed in patch 0, about marking some versus marking all? If so, I believe I should have answered it there. If not, please explain. >> This is done by the invocation of >> __free_accounted_pages() and free_accounted_pages(). > > These are very general-sounding names. I'd expect the identifiers to > contain "memcg" and/or "kmem", to identify what's going on. > Changed.
creator: Glauber Costa
date: 2012-10-18T09:24:47-00:00

Re: [PATCH v5 11/14] memcg: allow a memcg with kmem charges to be destructed.
type: item
description: On 10/18/2012 02:12 AM, Andrew Morton wrote: > On Tue, 16 Oct 2012 14:16:48 +0400 > Glauber Costa <glommer@parallels.com> wrote: > >> Because the ultimate goal of the kmem tracking in memcg is to track slab >> pages as well, > > It is? For a major patchset such as this, it's pretty important to > discuss such long-term plans in the top-level discussion. Covering > things such as expected complexity, expected performance hit, how these > plans affected the current implementation, etc. > > The main reason for this is that if the future plans appear to be of > doubtful feasibility and the current implementation isn't sufficiently > useful without the future stuff, we shouldn't merge the current > implementation. It's a big issue! > Not really. I am not talking about plans when it comes to slab. The code is there, and usually always posted to linux-mm a few days after I post this series. It also lives in the kmemcg-slab branch in my git tree. I am trying to logically split it in two to aid reviewers work. I may have made a mistake by splitting it this way, but so far I think it was the right decision: it allowed people to focus on a part of the work first, instead of going all the way in a 30-patch patch series that would be merged atomically. I believe they should be merged separately, to allow us to find any issues easier. But I also believe that this "separate" should ultimately live in the same merge window. Pekka, from the slab side, already stated that 3.8 would not be unreasonable. As for the perfomance hit, my latest benchmark, quoted in the opening mail of this series already include results for both patchsets.
creator: Glauber Costa
date: 2012-10-18T09:33:54-00:00

Re: [PATCH v5 13/14] protect architectures where THREAD_SIZE &gt;= PAGE_SIZE against fork bombs
type: item
description: On 10/18/2012 02:12 AM, Andrew Morton wrote: > On Tue, 16 Oct 2012 14:16:50 +0400 > Glauber Costa <glommer@parallels.com> wrote: > >> @@ -146,7 +146,7 @@ void __weak arch_release_thread_info(struct thread_info *ti) >> static struct thread_info *alloc_thread_info_node(struct task_struct *tsk, >> int node) >> { >> - struct page *page = alloc_pages_node(node, THREADINFO_GFP, >> + struct page *page = alloc_pages_node(node, THREADINFO_GFP_ACCOUNTED, >> THREAD_SIZE_ORDER); > > yay, we actually used all this code for something ;) > Happy to be of use, sir! > I don't think we really saw a comprehensive list of what else the kmem > controller will be used for, but I believe that all other envisaged > applications will require slab accounting, yes? > > > So it appears that all we have at present is a > yet-another-fork-bomb-preventer, but one which requires that the > culprit be in a container? That's reasonable, given your > hosted-environment scenario. It's unclear (to me) that we should merge > all this code for only this feature. Again, it would be good to have a > clear listing of and plan for other applications of this code. > I agree. This doesn't buy me much without slab accounting. But reiterating what I've just said in another e-mail, slab accounting is not really in plan stage, but had also been through extensive development. As a matter of fact, it used to be only "slab accounting" in the beginning, without this. I've split it more recently because I believe it would allow people to do a more focused review, leading to better code.
creator: Glauber Costa
date: 2012-10-18T09:37:39-00:00

Re: [PATCH v5 14/14] Add documentation about the kmem controller
type: item
description: On 10/18/2012 02:12 AM, Andrew Morton wrote: > On Tue, 16 Oct 2012 14:16:51 +0400 > Glauber Costa <glommer@parallels.com> wrote: > >> +Kernel memory won't be accounted at all until limit on a group is set. This >> +allows for existing setups to continue working without disruption. The limit >> +cannot be set if the cgroup have children, or if there are already tasks in the >> +cgroup. > > What behaviour will usersapce see if "The limit cannot be set"? > write() returns -EINVAL, something like that? > -EBUSY. Will update.
creator: Glauber Costa
date: 2012-10-18T09:38:08-00:00

Re: [PATCH v5 09/14] memcg: kmem accounting lifecycle management
type: item
description: On 10/18/2012 03:28 AM, David Rientjes wrote: > On Tue, 16 Oct 2012, Glauber Costa wrote: > >> diff --git a/mm/memcontrol.c b/mm/memcontrol.c >> index 1182188..e24b388 100644 >> --- a/mm/memcontrol.c >> +++ b/mm/memcontrol.c >> @@ -344,6 +344,7 @@ struct mem_cgroup { >> /* internal only representation about the status of kmem accounting. */ >> enum { >> KMEM_ACCOUNTED_ACTIVE = 0, /* accounted by this cgroup itself */ >> + KMEM_ACCOUNTED_DEAD, /* dead memcg, pending kmem charges */ > > "dead memcg with pending kmem charges" seems better. > ok. >> }; >> >> #define KMEM_ACCOUNTED_MASK (1 << KMEM_ACCOUNTED_ACTIVE) >> @@ -353,6 +354,22 @@ static void memcg_kmem_set_active(struct mem_cgroup *memcg) >> { >> set_bit(KMEM_ACCOUNTED_ACTIVE, &memcg->kmem_accounted); >> } >> + >> +static bool memcg_kmem_is_active(struct mem_cgroup *memcg) >> +{ >> + return test_bit(KMEM_ACCOUNTED_ACTIVE, &memcg->kmem_accounted); >> +} > > I think all of these should be inline. > They end up being, to be best of my knowledge the compiler can and will inline such simple functions regardless of their marking, unless you explicitly mark them noinline. >> + >> +static void memcg_kmem_mark_dead(struct mem_cgroup *memcg) >> +{ >> + if (test_bit(KMEM_ACCOUNTED_ACTIVE, &memcg->kmem_accounted)) >> + set_bit(KMEM_ACCOUNTED_DEAD, &memcg->kmem_accounted); >> +} > > The set_bit() doesn't happen atomically with the test_bit(), what > synchronization is required for this? > I believe the explanation Michal gave in answer to this is comprehensive.
creator: Glauber Costa
date: 2012-10-18T09:42:11-00:00

Re: [PATCH v5 07/14] mm: Allocate kernel pages to the right memcg
type: item
description: On 10/18/2012 02:12 AM, Andrew Morton wrote: > On Tue, 16 Oct 2012 14:16:44 +0400 > Glauber Costa <glommer@parallels.com> wrote: > >> When a process tries to allocate a page with the __GFP_KMEMCG flag, the >> page allocator will call the corresponding memcg functions to validate >> the allocation. Tasks in the root memcg can always proceed. >> >> To avoid adding markers to the page - and a kmem flag that would >> necessarily follow, as much as doing page_cgroup lookups for no reason, >> whoever is marking its allocations with __GFP_KMEMCG flag is responsible >> for telling the page allocator that this is such an allocation at >> free_pages() time. > > Well, why? Was that the correct decision? > >> This is done by the invocation of >> __free_accounted_pages() and free_accounted_pages(). > > These are very general-sounding names. I'd expect the identifiers to > contain "memcg" and/or "kmem", to identify what's going on. > I've just changed to free_memcg_kmem_pages. Let me know if the name is better.
creator: Glauber Costa
date: 2012-10-18T11:53:37-00:00

Re: [PATCH v5 00/14] kmem controller for memcg.
type: item
description: On Thu, 18 Oct 2012 20:51:05 +0400 Glauber Costa <glommer@parallels.com> wrote: > On 10/18/2012 02:11 AM, Andrew Morton wrote: > > On Tue, 16 Oct 2012 14:16:37 +0400 > > Glauber Costa <glommer@parallels.com> wrote: > > > >> ... > >> > >> A general explanation of what this is all about follows: > >> > >> The kernel memory limitation mechanism for memcg concerns itself with > >> disallowing potentially non-reclaimable allocations to happen in exaggerate > >> quantities by a particular set of processes (cgroup). Those allocations could > >> create pressure that affects the behavior of a different and unrelated set of > >> processes. > >> > >> Its basic working mechanism is to annotate some allocations with the > >> _GFP_KMEMCG flag. When this flag is set, the current process allocating will > >> have its memcg identified and charged against. When reaching a specific limit, > >> further allocations will be denied. > > > > The need to set _GFP_KMEMCG is rather unpleasing, and makes one wonder > > "why didn't it just track all allocations". > > > This was raised as well by Peter Zijlstra during the memcg summit. Firstly: please treat any question from a reviewer as an indication that information was missing from the changelog or from code comments. Ideally all such queries are addressed in later version of the patch and changelog. > The > answer I gave to him still stands: There is a cost associated with it. > We believe it comes down to a trade off situation. How much tracking a > particular kind of allocation help vs how much does it cost. > > The free path is specially more expensive, since it will always incur in > a page_cgroup lookup. OK. But that is a quantitative argument, without any quantities! Do we have even an estimate of what this cost will be? Perhaps it's the case that, if well implemented, that cost will be acceptable. How do we tell? > > Does this mean that over time we can expect more sites to get the > > _GFP_KMEMCG tagging? > > We have being doing ker…
creator: akpm
date: 2012-10-18T19:21:05-00:00

Re: [PATCH v5 04/14] kmem accounting basic infrastructure
type: item
description: Hello, David. On Wed, Oct 17, 2012 at 03:08:04PM -0700, David Rientjes wrote: > > +static int memcg_update_kmem_limit(struct cgroup *cont, u64 val) > > +{ > > + int ret = -EINVAL; > > +#ifdef CONFIG_MEMCG_KMEM > > + struct mem_cgroup *memcg = mem_cgroup_from_cont(cont); > > + /* > > + * For simplicity, we won't allow this to be disabled. It also can't > > + * be changed if the cgroup has children already, or if tasks had > > + * already joined. > > + * > > + * If tasks join before we set the limit, a person looking at > > + * kmem.usage_in_bytes will have no way to determine when it took > > + * place, which makes the value quite meaningless. > > + * > > + * After it first became limited, changes in the value of the limit are > > + * of course permitted. > > + * > > + * Taking the cgroup_lock is really offensive, but it is so far the only > > + * way to guarantee that no children will appear. There are plenty of > > + * other offenders, and they should all go away. Fine grained locking > > + * is probably the way to go here. When we are fully hierarchical, we > > + * can also get rid of the use_hierarchy check. > > Not sure it's so offensive, it's a pretty standard way of ensuring that > cont->children doesn't get manipulated in a race. cgroup_lock is inherently one of the outermost locks as it protects cgroup hierarchy and modifying cgroup hierarchy involves invoking subsystem callbacks which may grab subsystem locks. Grabbing it directly from subsystems thus creates high likelihood of creating a dependency loop and it's nasty to break. And I'm unsure whether making cgroup locks finer grained would help as cpuset grabs cgroup_lock to perform actual task migration which would require the outermost cgroup locking anyway. This one already has showed up in a couple lockdep warnings involving static_key usages. A couple days ago, I posted a patchset to remove cgroup_lock usage from cgroup_freezer and at least cgroup_freezer seems like it was aiming for the wrong behavio…
creator: Tejun Heo
date: 2012-10-18T19:37:17-00:00

Re: [PATCH v5 04/14] kmem accounting basic infrastructure
type: item
description: Hey, Glauber. On Thu, Oct 18, 2012 at 09:01:23PM +0400, Glauber Costa wrote: > That is the offensive part. But it is also how things are done in memcg > right now, and there is nothing fundamentally different in this one. > Whatever lands in the remaining offenders, can land in here. I think the problem here is that we don't have "you're committing to creation of a new cgroup" callback and thus subsystem can't synchronize locally against cgroup creation. For task migration ->attach() does that but cgroup creation may fail after ->create() succeeded so that doesn't work. We'll probably need to add ->post_create() which is invoked after creation is complete. Li? Thanks. -- tejun
creator: Tejun Heo
date: 2012-10-18T19:47:27-00:00

Re: [PATCH v5 07/14] mm: Allocate kernel pages to the right memcg
type: item
description: On Thu, 18 Oct 2012 13:24:47 +0400 Glauber Costa <glommer@parallels.com> wrote: > On 10/18/2012 02:12 AM, Andrew Morton wrote: > > On Tue, 16 Oct 2012 14:16:44 +0400 > > Glauber Costa <glommer@parallels.com> wrote: > > > >> When a process tries to allocate a page with the __GFP_KMEMCG flag, the > >> page allocator will call the corresponding memcg functions to validate > >> the allocation. Tasks in the root memcg can always proceed. > >> > >> To avoid adding markers to the page - and a kmem flag that would > >> necessarily follow, as much as doing page_cgroup lookups for no reason, > >> whoever is marking its allocations with __GFP_KMEMCG flag is responsible > >> for telling the page allocator that this is such an allocation at > >> free_pages() time. > > > > Well, why? Was that the correct decision? > > > > I don't fully understand your question. Is this the same question you > posed in patch 0, about marking some versus marking all? If so, I > believe I should have answered it there. Yes, it's the same question. The one which has not yet been fully answered ;)
creator: akpm
date: 2012-10-18T20:44:57-00:00

Re: [PATCH v5 06/14] memcg: kmem controller infrastructure
type: item
description: On Thu, 18 Oct 2012, Glauber Costa wrote: > >> @@ -2630,6 +2634,171 @@ static void __mem_cgroup_commit_charge(struct mem_cgroup *memcg, > >> memcg_check_events(memcg, page); > >> } > >> > >> +#ifdef CONFIG_MEMCG_KMEM > >> +static inline bool memcg_can_account_kmem(struct mem_cgroup *memcg) > >> +{ > >> + return !mem_cgroup_disabled() && !mem_cgroup_is_root(memcg) && > >> + (memcg->kmem_accounted & KMEM_ACCOUNTED_MASK); > >> +} > >> + > >> +static int memcg_charge_kmem(struct mem_cgroup *memcg, gfp_t gfp, u64 size) > >> +{ > >> + struct res_counter *fail_res; > >> + struct mem_cgroup *_memcg; > >> + int ret = 0; > >> + bool may_oom; > >> + > >> + ret = res_counter_charge(&memcg->kmem, size, &fail_res); > >> + if (ret) > >> + return ret; > >> + > >> + /* > >> + * Conditions under which we can wait for the oom_killer. > >> + * We have to be able to wait, but also, if we can't retry, > >> + * we obviously shouldn't go mess with oom. > >> + */ > >> + may_oom = (gfp & __GFP_WAIT) && !(gfp & __GFP_NORETRY); > > > > What about gfp & __GFP_FS? > > > > Do you intend to prevent or allow OOM under that flag? I personally > think that anything that accepts to be OOM-killed should have GFP_WAIT > set, so that ought to be enough. > The oom killer in the page allocator cannot trigger without __GFP_FS because direct reclaim has little chance of being very successful and thus we end up needlessly killing processes, and that tends to happen quite a bit if we dont check for it. Seems like this would also happen with memcg if mem_cgroup_reclaim() has a large probability of failing?
creator: David Rientjes
date: 2012-10-18T21:59:44-00:00

Re: [PATCH v5 06/14] memcg: kmem controller infrastructure
type: item
description: On Thu, 18 Oct 2012, Glauber Costa wrote: > > Do we actually need to test PF_KTHREAD when current->mm == NULL? > > Perhaps because of aio threads whcih temporarily adopt a userspace mm? > > I believe so. I remember I discussed this in the past with David > Rientjes and he advised me to test for both. > PF_KTHREAD can do use_mm() to assume an ->mm but hopefully they aren't allocating slab while doing so. Have you considered actually charging current->mm->owner for that memory, though, since the kthread will have freed the memory before unuse_mm() or otherwise have charged it on behalf of a user process, i.e. only exempting PF_KTHREAD?
creator: David Rientjes
date: 2012-10-18T22:06:54-00:00

Re: [PATCH v5 06/14] memcg: kmem controller infrastructure
type: item
description: On 10/19/2012 02:06 AM, David Rientjes wrote: > On Thu, 18 Oct 2012, Glauber Costa wrote: > >>> Do we actually need to test PF_KTHREAD when current->mm == NULL? >>> Perhaps because of aio threads whcih temporarily adopt a userspace mm? >> >> I believe so. I remember I discussed this in the past with David >> Rientjes and he advised me to test for both. >> > > PF_KTHREAD can do use_mm() to assume an ->mm but hopefully they aren't > allocating slab while doing so. Have you considered actually charging > current->mm->owner for that memory, though, since the kthread will have > freed the memory before unuse_mm() or otherwise have charged it on behalf > of a user process, i.e. only exempting PF_KTHREAD? > I always charge current->mm->owner.
creator: Glauber Costa
date: 2012-10-19T09:10:27-00:00

Re: [PATCH v5 06/14] memcg: kmem controller infrastructure
type: item
description: On Fri, 19 Oct 2012, Glauber Costa wrote: > >>> Do we actually need to test PF_KTHREAD when current->mm == NULL? > >>> Perhaps because of aio threads whcih temporarily adopt a userspace mm? > >> > >> I believe so. I remember I discussed this in the past with David > >> Rientjes and he advised me to test for both. > >> > > > > PF_KTHREAD can do use_mm() to assume an ->mm but hopefully they aren't > > allocating slab while doing so. Have you considered actually charging > > current->mm->owner for that memory, though, since the kthread will have > > freed the memory before unuse_mm() or otherwise have charged it on behalf > > of a user process, i.e. only exempting PF_KTHREAD? > > > I always charge current->mm->owner. > Yeah, I'm asking have you considered charging current->mm->owner for the memory when a kthread (current) assumes the mm of a user process via use_mm()? It may free the memory before calling unuse_mm(), but it's also allocating the memory on behalf of a user so this exemption might be dangerous if use_mm() becomes more popular. I don't think there's anything that prevents that charge, I'm just wondering if you considered doing it even for kthreads with an mm.
creator: David Rientjes
date: 2012-10-19T09:31:33-00:00

Re: [PATCH v5 00/14] kmem controller for memcg.
type: item
description: On 10/18/2012 11:21 PM, Andrew Morton wrote: > On Thu, 18 Oct 2012 20:51:05 +0400 > Glauber Costa <glommer@parallels.com> wrote: > >> On 10/18/2012 02:11 AM, Andrew Morton wrote: >>> On Tue, 16 Oct 2012 14:16:37 +0400 >>> Glauber Costa <glommer@parallels.com> wrote: >>> >>>> ... >>>> >>>> A general explanation of what this is all about follows: >>>> >>>> The kernel memory limitation mechanism for memcg concerns itself with >>>> disallowing potentially non-reclaimable allocations to happen in exaggerate >>>> quantities by a particular set of processes (cgroup). Those allocations could >>>> create pressure that affects the behavior of a different and unrelated set of >>>> processes. >>>> >>>> Its basic working mechanism is to annotate some allocations with the >>>> _GFP_KMEMCG flag. When this flag is set, the current process allocating will >>>> have its memcg identified and charged against. When reaching a specific limit, >>>> further allocations will be denied. >>> >>> The need to set _GFP_KMEMCG is rather unpleasing, and makes one wonder >>> "why didn't it just track all allocations". >>> >> This was raised as well by Peter Zijlstra during the memcg summit. > > Firstly: please treat any question from a reviewer as an indication > that information was missing from the changelog or from code comments. > Ideally all such queries are addressed in later version of the patch > and changelog. > This is in no opposition with me telling a bit that this has been raised before! =) >> The >> answer I gave to him still stands: There is a cost associated with it. >> We believe it comes down to a trade off situation. How much tracking a >> particular kind of allocation help vs how much does it cost. >> >> The free path is specially more expensive, since it will always incur in >> a page_cgroup lookup. > > OK. But that is a quantitative argument, without any quantities! Do > we have even an estimate of what this cost will be? Perhaps it's the > case that, if well implemented, that…
creator: Glauber Costa
date: 2012-10-19T09:55:05-00:00

Re: [PATCH v5 06/14] memcg: kmem controller infrastructure
type: item
description: On 10/19/2012 01:31 PM, David Rientjes wrote: > On Fri, 19 Oct 2012, Glauber Costa wrote: > >>>>> Do we actually need to test PF_KTHREAD when current->mm == NULL? >>>>> Perhaps because of aio threads whcih temporarily adopt a userspace mm? >>>> >>>> I believe so. I remember I discussed this in the past with David >>>> Rientjes and he advised me to test for both. >>>> >>> >>> PF_KTHREAD can do use_mm() to assume an ->mm but hopefully they aren't >>> allocating slab while doing so. Have you considered actually charging >>> current->mm->owner for that memory, though, since the kthread will have >>> freed the memory before unuse_mm() or otherwise have charged it on behalf >>> of a user process, i.e. only exempting PF_KTHREAD? >>> >> I always charge current->mm->owner. >> > > Yeah, I'm asking have you considered charging current->mm->owner for the > memory when a kthread (current) assumes the mm of a user process via > use_mm()? It may free the memory before calling unuse_mm(), but it's also > allocating the memory on behalf of a user so this exemption might be > dangerous if use_mm() becomes more popular. I don't think there's > anything that prevents that charge, I'm just wondering if you considered > doing it even for kthreads with an mm. > Well, I thought about it. And I personally don't like it. I think all kthreads should be treated the same. We have control over it, unlike any userspace application. We never expect its memory consumption to explode. Specially considering that those allocations are supposed to be short-lived, we are only paying the res_counters count for no reason.
creator: Glauber Costa
date: 2012-10-19T10:00:23-00:00

Re: [PATCH v5 06/14] memcg: kmem controller infrastructure
type: item
description: On 10/19/2012 01:59 AM, David Rientjes wrote: > On Thu, 18 Oct 2012, Glauber Costa wrote: > >>>> @@ -2630,6 +2634,171 @@ static void __mem_cgroup_commit_charge(struct mem_cgroup *memcg, >>>> memcg_check_events(memcg, page); >>>> } >>>> >>>> +#ifdef CONFIG_MEMCG_KMEM >>>> +static inline bool memcg_can_account_kmem(struct mem_cgroup *memcg) >>>> +{ >>>> + return !mem_cgroup_disabled() && !mem_cgroup_is_root(memcg) && >>>> + (memcg->kmem_accounted & KMEM_ACCOUNTED_MASK); >>>> +} >>>> + >>>> +static int memcg_charge_kmem(struct mem_cgroup *memcg, gfp_t gfp, u64 size) >>>> +{ >>>> + struct res_counter *fail_res; >>>> + struct mem_cgroup *_memcg; >>>> + int ret = 0; >>>> + bool may_oom; >>>> + >>>> + ret = res_counter_charge(&memcg->kmem, size, &fail_res); >>>> + if (ret) >>>> + return ret; >>>> + >>>> + /* >>>> + * Conditions under which we can wait for the oom_killer. >>>> + * We have to be able to wait, but also, if we can't retry, >>>> + * we obviously shouldn't go mess with oom. >>>> + */ >>>> + may_oom = (gfp & __GFP_WAIT) && !(gfp & __GFP_NORETRY); >>> >>> What about gfp & __GFP_FS? >>> >> >> Do you intend to prevent or allow OOM under that flag? I personally >> think that anything that accepts to be OOM-killed should have GFP_WAIT >> set, so that ought to be enough. >> > > The oom killer in the page allocator cannot trigger without __GFP_FS > because direct reclaim has little chance of being very successful and > thus we end up needlessly killing processes, and that tends to happen > quite a bit if we dont check for it. Seems like this would also happen > with memcg if mem_cgroup_reclaim() has a large probability of failing? > I can indeed see tests for GFP_FS in some key locations in mm/ before calling the OOM Killer. Should I test for GFP_IO as well? If the idea is preventing OOM to trigger for allocations that can write their pages back, how would you feel about the following test: may_oom = (gfp & GFP_KERNEL) && !(gfp & __GFP_NORETRY) ? Michal, what is your ta…
creator: Glauber Costa
date: 2012-10-19T10:08:27-00:00

Re: [PATCH v5 06/14] memcg: kmem controller infrastructure
type: item
description: On Fri, 19 Oct 2012, Glauber Costa wrote: > >>> What about gfp & __GFP_FS? > >>> > >> > >> Do you intend to prevent or allow OOM under that flag? I personally > >> think that anything that accepts to be OOM-killed should have GFP_WAIT > >> set, so that ought to be enough. > >> > > > > The oom killer in the page allocator cannot trigger without __GFP_FS > > because direct reclaim has little chance of being very successful and > > thus we end up needlessly killing processes, and that tends to happen > > quite a bit if we dont check for it. Seems like this would also happen > > with memcg if mem_cgroup_reclaim() has a large probability of failing? > > > > I can indeed see tests for GFP_FS in some key locations in mm/ before > calling the OOM Killer. > > Should I test for GFP_IO as well? It's not really necessary, if __GFP_IO isn't set then it wouldn't make sense for __GFP_FS to be set. > If the idea is preventing OOM to > trigger for allocations that can write their pages back, how would you > feel about the following test: > > may_oom = (gfp & GFP_KERNEL) && !(gfp & __GFP_NORETRY) ? > I would simply copy the logic from the page allocator and only trigger oom for __GFP_FS and !__GFP_NORETRY.
creator: David Rientjes
date: 2012-10-19T20:34:04-00:00

Re: [PATCH v5 06/14] memcg: kmem controller infrastructure
type: item
description: On 10/20/2012 12:34 AM, David Rientjes wrote: > On Fri, 19 Oct 2012, Glauber Costa wrote: > >>>>> What about gfp & __GFP_FS? >>>>> >>>> >>>> Do you intend to prevent or allow OOM under that flag? I personally >>>> think that anything that accepts to be OOM-killed should have GFP_WAIT >>>> set, so that ought to be enough. >>>> >>> >>> The oom killer in the page allocator cannot trigger without __GFP_FS >>> because direct reclaim has little chance of being very successful and >>> thus we end up needlessly killing processes, and that tends to happen >>> quite a bit if we dont check for it. Seems like this would also happen >>> with memcg if mem_cgroup_reclaim() has a large probability of failing? >>> >> >> I can indeed see tests for GFP_FS in some key locations in mm/ before >> calling the OOM Killer. >> >> Should I test for GFP_IO as well? > > It's not really necessary, if __GFP_IO isn't set then it wouldn't make > sense for __GFP_FS to be set. > >> If the idea is preventing OOM to >> trigger for allocations that can write their pages back, how would you >> feel about the following test: >> >> may_oom = (gfp & GFP_KERNEL) && !(gfp & __GFP_NORETRY) ? >> > > I would simply copy the logic from the page allocator and only trigger oom > for __GFP_FS and !__GFP_NORETRY. > That seems reasonable to me. Michal ?
creator: Glauber Costa
date: 2012-10-22T12:34:15-00:00

Re: [PATCH v5 06/14] memcg: kmem controller infrastructure
type: item
description: [Sorry for the late reply] On Mon 22-10-12 16:34:15, Glauber Costa wrote: > On 10/20/2012 12:34 AM, David Rientjes wrote: > > On Fri, 19 Oct 2012, Glauber Costa wrote: > > > >>>>> What about gfp & __GFP_FS? > >>>>> > >>>> > >>>> Do you intend to prevent or allow OOM under that flag? I personally > >>>> think that anything that accepts to be OOM-killed should have GFP_WAIT > >>>> set, so that ought to be enough. > >>>> > >>> > >>> The oom killer in the page allocator cannot trigger without __GFP_FS > >>> because direct reclaim has little chance of being very successful and > >>> thus we end up needlessly killing processes, and that tends to happen > >>> quite a bit if we dont check for it. Seems like this would also happen > >>> with memcg if mem_cgroup_reclaim() has a large probability of failing? > >>> > >> > >> I can indeed see tests for GFP_FS in some key locations in mm/ before > >> calling the OOM Killer. > >> > >> Should I test for GFP_IO as well? > > > > It's not really necessary, if __GFP_IO isn't set then it wouldn't make > > sense for __GFP_FS to be set. > > > >> If the idea is preventing OOM to > >> trigger for allocations that can write their pages back, how would you > >> feel about the following test: > >> > >> may_oom = (gfp & GFP_KERNEL) && !(gfp & __GFP_NORETRY) ? > >> > > > > I would simply copy the logic from the page allocator and only trigger oom > > for __GFP_FS and !__GFP_NORETRY. > > > > That seems reasonable to me. Michal ? Yes it makes sense to be consistent with the global case. While we are at it, do we need to consider PF_DUMPCORE resp. !__GFP_NOFAIL? -- Michal Hocko SUSE Labs
creator: Michal Hocko
date: 2012-10-22T12:51:24-00:00

Re: [PATCH v5 06/14] memcg: kmem controller infrastructure
type: item
description: On 10/22/2012 04:51 PM, Michal Hocko wrote: > [Sorry for the late reply] > > On Mon 22-10-12 16:34:15, Glauber Costa wrote: >> On 10/20/2012 12:34 AM, David Rientjes wrote: >>> On Fri, 19 Oct 2012, Glauber Costa wrote: >>> >>>>>>> What about gfp & __GFP_FS? >>>>>>> >>>>>> >>>>>> Do you intend to prevent or allow OOM under that flag? I personally >>>>>> think that anything that accepts to be OOM-killed should have GFP_WAIT >>>>>> set, so that ought to be enough. >>>>>> >>>>> >>>>> The oom killer in the page allocator cannot trigger without __GFP_FS >>>>> because direct reclaim has little chance of being very successful and >>>>> thus we end up needlessly killing processes, and that tends to happen >>>>> quite a bit if we dont check for it. Seems like this would also happen >>>>> with memcg if mem_cgroup_reclaim() has a large probability of failing? >>>>> >>>> >>>> I can indeed see tests for GFP_FS in some key locations in mm/ before >>>> calling the OOM Killer. >>>> >>>> Should I test for GFP_IO as well? >>> >>> It's not really necessary, if __GFP_IO isn't set then it wouldn't make >>> sense for __GFP_FS to be set. >>> >>>> If the idea is preventing OOM to >>>> trigger for allocations that can write their pages back, how would you >>>> feel about the following test: >>>> >>>> may_oom = (gfp & GFP_KERNEL) && !(gfp & __GFP_NORETRY) ? >>>> >>> >>> I would simply copy the logic from the page allocator and only trigger oom >>> for __GFP_FS and !__GFP_NORETRY. >>> >> >> That seems reasonable to me. Michal ? > > Yes it makes sense to be consistent with the global case. While we are > at it, do we need to consider PF_DUMPCORE resp. !__GFP_NOFAIL? > at least from kmem, GFP_NOFAIL will not reach this codepath. We will ditch it to the root in memcontrol.h
creator: Glauber Costa
date: 2012-10-22T12:52:41-00:00