Re: [Devel] call_usermodehelper in containers

On 2016/02/19 14:37, Ian Kent wrote: On Fri, 2016-02-19 at 12:08 +0900, Kamezawa Hiroyuki wrote: On 2016/02/19 5:45, Eric W. Biederman wrote: Personally I am a fan of the don't be clever and capture a kernel thread approach as it is very easy to see you what if any exploitation opportunities

Re: [Devel] call_usermodehelper in containers

On 2016/02/19 5:45, Eric W. Biederman wrote: > Personally I am a fan of the don't be clever and capture a kernel thread > approach as it is very easy to see you what if any exploitation > opportunities there are. The justifications for something more clever > is trickier. Of course we do

Re: [Devel] call_usermodehelper in containers

On 2016/02/18 11:57, Eric W. Biederman wrote: > > Ccing The containers list because a related discussion is happening there > and somehow this thread has never made it there. > > Ian Kent writes: > >> On Mon, 2013-11-18 at 18:28 +0100, Oleg Nesterov wrote: >>> On 11/15, Eric

[Devel] Re: [PATCH v5 06/14] memcg: kmem controller infrastructure

: Christoph Lameter c...@linux.com CC: Pekka Enberg penb...@cs.helsinki.fi CC: Kamezawa Hiroyuki kamezawa.hir...@jp.fujitsu.com CC: Johannes Weiner han...@cmpxchg.org CC: Tejun Heo t...@kernel.org Acked-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com

[Devel] Re: [PATCH v5 12/14] execute the whole memcg freeing in free_worker

...@parallels.com Tested-by: Greg Thelen gthe...@google.com Acked-by: Michal Hocko mho...@suse.cz CC: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com CC: Johannes Weiner han...@cmpxchg.org CC: Tejun Heo t...@kernel.org Acked-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com

[Devel] Re: [PATCH v4 14/14] Add documentation about the kmem controller

(2012/10/08 19:06), Glauber Costa wrote: Signed-off-by: Glauber Costa glom...@parallels.com --- Documentation/cgroups/memory.txt | 55 +++- 1 file changed, 54 insertions(+), 1 deletion(-) Acked-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com

[Devel] Re: [PATCH v4 06/14] memcg: kmem controller infrastructure

(2012/10/12 18:13), Glauber Costa wrote: On 10/12/2012 12:57 PM, Michal Hocko wrote: On Fri 12-10-12 12:44:57, Glauber Costa wrote: On 10/12/2012 12:39 PM, Michal Hocko wrote: On Fri 12-10-12 11:45:46, Glauber Costa wrote: On 10/11/2012 04:42 PM, Michal Hocko wrote: On Mon 08-10-12

[Devel] Re: [PATCH v4 08/14] res_counter: return amount of charges after res_counter_uncharge

this value. Signed-off-by: Glauber Costa glom...@parallels.com CC: Michal Hocko mho...@suse.cz CC: Johannes Weiner han...@cmpxchg.org CC: Suleiman Souhlal sulei...@google.com CC: Kamezawa Hiroyuki kamezawa.hir...@jp.fujitsu.com --- Documentation/cgroups/resource_counter.txt | 7

[Devel] Re: [PATCH v4 09/14] memcg: kmem accounting lifecycle management

] Signed-off-by: Glauber Costa glom...@parallels.com CC: Kamezawa Hiroyuki kamezawa.hir...@jp.fujitsu.com CC: Christoph Lameter c...@linux.com CC: Pekka Enberg penb...@cs.helsinki.fi CC: Michal Hocko mho...@suse.cz CC: Johannes Weiner han...@cmpxchg.org CC: Suleiman Souhlal sulei...@google.com OK, I

[Devel] Re: [PATCH v4 10/14] memcg: use static branches when code not in use

. 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 glom...@parallels.com CC: Kamezawa Hiroyuki kamezawa.hir...@jp.fujitsu.com CC: Christoph Lameter c...@linux.com CC

[Devel] Re: [PATCH v4 02/14] memcg: Reclaim when more than one page needed.

sure not to do it if __GFP_NORETRY. [v4: fixed nr pages calculation pointed out by Christoph Lameter ] Signed-off-by: Suleiman Souhlal sulei...@google.com Signed-off-by: Glauber Costa glom...@parallels.com Reviewed-by: Kamezawa Hiroyuki kamezawa.hir...@jp.fujitsu.com Acked-by: Michal Hocko

[Devel] Re: [PATCH v2 06/11] memcg: kmem controller infrastructure

(2012/08/13 17:28), Glauber Costa wrote: + * Needs to be called after memcg_kmem_new_page, 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 @handle to the + * corresponding

[Devel] Re: [PATCH v2 04/11] kmem accounting basic infrastructure

(2012/08/13 17:36), Glauber Costa wrote: On 08/10/2012 09:02 PM, Kamezawa Hiroyuki wrote: (2012/08/09 22:01), Glauber Costa wrote: This patch adds the basic infrastructure for the accounting of the slab caches. To control that, the following files are created: * memory.kmem.usage_in_bytes

[Devel] Re: [PATCH v2 02/11] memcg: Reclaim when more than one page needed.

(2012/08/11 0:42), Michal Hocko wrote: On Thu 09-08-12 17:01:10, Glauber Costa wrote: [...] @@ -2317,18 +2318,18 @@ static int mem_cgroup_do_charge(struct mem_cgroup *memcg, gfp_t gfp_mask, } else mem_over_limit = mem_cgroup_from_res_counter(fail_res, res); /* -

[Devel] Re: [PATCH v2 04/11] kmem accounting basic infrastructure

...@parallels.com CC: Michal Hocko mho...@suse.cz CC: Johannes Weiner han...@cmpxchg.org Reviewed-by: Kamezawa Hiroyuki kamezawa.hir...@jp.fujitsu.com Could you add a patch for documentation of this new interface and a text explaining the behavior of kmem_accounting ? Hm, my concern is the difference

[Devel] Re: [PATCH v2 05/11] Add a __GFP_KMEMCG flag

Costa glom...@parallels.com CC: Christoph Lameter c...@linux.com CC: Pekka Enberg penb...@cs.helsinki.fi CC: Michal Hocko mho...@suse.cz CC: Kamezawa Hiroyuki kamezawa.hir...@jp.fujitsu.com CC: Johannes Weiner han...@cmpxchg.org CC: Suleiman Souhlal sulei...@google.com CC: Rik van Riel r

[Devel] Re: [PATCH v2 06/11] memcg: kmem controller infrastructure

: Christoph Lameter c...@linux.com CC: Pekka Enberg penb...@cs.helsinki.fi CC: Michal Hocko mho...@suse.cz CC: Kamezawa Hiroyuki kamezawa.hir...@jp.fujitsu.com CC: Johannes Weiner han...@cmpxchg.org --- include/linux/memcontrol.h | 79 +++ mm/memcontrol.c| 185

[Devel] Re: [PATCH v2 07/11] mm: Allocate kernel pages to the right memcg

of __free_accounted_pages() and free_accounted_pages(). Signed-off-by: Glauber Costa glom...@parallels.com CC: Christoph Lameter c...@linux.com CC: Pekka Enberg penb...@cs.helsinki.fi CC: Michal Hocko mho...@suse.cz CC: Kamezawa Hiroyuki kamezawa.hir...@jp.fujitsu.com CC: Johannes Weiner han...@cmpxchg.org

[Devel] Re: [PATCH v2 09/11] memcg: propagate kmem limiting information to children

: Pekka Enberg penb...@cs.helsinki.fi CC: Michal Hocko mho...@suse.cz CC: Kamezawa Hiroyuki kamezawa.hir...@jp.fujitsu.com CC: Johannes Weiner han...@cmpxchg.org CC: Suleiman Souhlal sulei...@google.com --- mm/memcontrol.c | 88

[Devel] Re: [PATCH v2 11/11] protect architectures where THREAD_SIZE = PAGE_SIZE against fork bombs

Costa glom...@parallels.com Acked-by: Frederic Weisbecker fweis...@redhat.com CC: Christoph Lameter c...@linux.com CC: Pekka Enberg penb...@cs.helsinki.fi CC: Michal Hocko mho...@suse.cz CC: Kamezawa Hiroyuki kamezawa.hir...@jp.fujitsu.com CC: Johannes Weiner han...@cmpxchg.org CC: Suleiman

[Devel] Re: [PATCH v2 02/11] memcg: Reclaim when more than one page needed.

(2012/08/11 2:28), Michal Hocko wrote: On Sat 11-08-12 01:49:25, KAMEZAWA Hiroyuki wrote: (2012/08/11 0:42), Michal Hocko wrote: On Thu 09-08-12 17:01:10, Glauber Costa wrote: [...] @@ -2317,18 +2318,18 @@ static int mem_cgroup_do_charge(struct mem_cgroup *memcg, gfp_t gfp_mask

[Devel] Re: containers and cgroups mini-summit @ Linux Plumbers

(2012/07/12 6:41), Kir Kolyshkin wrote: Gentlemen, We are organizing containers mini-summit during next Linux Plumbers (San Diego, August 29-31). The idea is to gather and discuss everything relevant to namespaces, cgroups, resource management, checkpoint-restore and so on. We are trying to

[Devel] Re: [PATCH 10/11] memcg: allow a memcg with kmem charges to be destructed.

Lameter c...@linux.com CC: Pekka Enberg penb...@cs.helsinki.fi CC: Michal Hocko mho...@suse.cz CC: Kamezawa Hiroyuki kamezawa.hir...@jp.fujitsu.com CC: Johannes Weiner han...@cmpxchg.org CC: Suleiman Souhlal sulei...@google.com --- mm/memcontrol.c | 10 +- 1 file changed, 9

[Devel] Re: [PATCH] fix bad behavior in use_hierarchy file

: Kamezawa Hiroyuki kamezawa.hir...@jp.fujitsu.com CC: Johannes Weiner han...@cmpxchg.org Hm. Acked-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel

[Devel] Re: [PATCH 11/11] protect architectures where THREAD_SIZE = PAGE_SIZE against fork bombs

(2012/06/26 13:57), David Rientjes wrote: On Mon, 25 Jun 2012, Glauber Costa wrote: diff --git a/include/linux/thread_info.h b/include/linux/thread_info.h index ccc1899..914ec07 100644 --- a/include/linux/thread_info.h +++ b/include/linux/thread_info.h @@ -61,6 +61,12 @@ extern long

[Devel] Re: [PATCH 08/11] memcg: disable kmem code when not in use.

...@linux.com CC: Pekka Enberg penb...@cs.helsinki.fi CC: Michal Hocko mho...@suse.cz CC: Kamezawa Hiroyuki kamezawa.hir...@jp.fujitsu.com CC: Johannes Weiner han...@cmpxchg.org CC: Suleiman Souhlal sulei...@google.com Acked-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com

[Devel] Re: [PATCH v4 23/25] memcg: propagate kmem limiting information to children

(2012/06/20 17:59), Glauber Costa wrote: On 06/19/2012 12:54 PM, Glauber Costa wrote: On 06/19/2012 12:35 PM, Glauber Costa wrote: On 06/19/2012 04:16 AM, Kamezawa Hiroyuki wrote: (2012/06/18 21:43), Glauber Costa wrote: On 06/18/2012 04:37 PM, Kamezawa Hiroyuki wrote: (2012/06/18 19:28

[Devel] Re: [PATCH v4 05/25] memcg: Always free struct memcg through schedule_work()

(2012/06/20 17:40), Glauber Costa wrote: On 06/20/2012 11:32 AM, Pekka Enberg wrote: Maybe Pekka can merge the current -mm with his tree? I first want to have a stable base from Christoph's common slab series before I am comfortable with going forward with the memcg parts. Feel free to push

[Devel] Re: [PATCH v4 05/25] memcg: Always free struct memcg through schedule_work()

first as simple cleanu up and to reduce patch stack on your side ? Acked-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com --- mm/memcontrol.c | 24 +--- 1 file changed, 13 insertions(+), 11 deletions(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index e3b528e

[Devel] Re: [PATCH v4 00/25] kmem limitation for memcg

(2012/06/18 19:27), Glauber Costa wrote: Hello All, This is my new take for the memcg kmem accounting. This should merge all of the previous comments from you guys, specially concerning the big churn inside the allocators themselves. My focus in this new round was to keep the changes in

[Devel] Re: [PATCH v4 17/25] skip memcg kmem allocations in specified code regions

...@suse.cz CC: Kamezawa Hiroyukikamezawa.hir...@jp.fujitsu.com CC: Johannes Weinerhan...@cmpxchg.org CC: Suleiman Souhlalsulei...@google.com I'm ok with this approach. Reviewed-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com ___ Devel mailing list

[Devel] Re: [PATCH v4 19/25] memcg: disable kmem code when not in use.

(2012/06/18 19:28), Glauber Costa wrote: We can use jump labels to patch the code in or out when not used. Because the assignment: memcg-kmem_accounted = true is done after the jump labels increment, we guarantee that the root memcg will always be selected until all call sites are patched

[Devel] Re: [PATCH v4 23/25] memcg: propagate kmem limiting information to children

(2012/06/18 19:28), Glauber Costa wrote: The current memcg slab cache management fails to present satisfatory hierarchical behavior in the following scenario: - /cgroups/memory/A/B/C * kmem limit set at A * A and B empty taskwise * bash in C does find / Because kmem_accounted is a

[Devel] Re: [PATCH v4 05/25] memcg: Always free struct memcg through schedule_work()

(2012/06/18 21:10), Glauber Costa wrote: On 06/18/2012 04:07 PM, Kamezawa Hiroyuki wrote: (2012/06/18 19:27), Glauber Costa wrote: Right now we free struct memcg with kfree right after a rcu grace period, but defer it if we need to use vfree() to get rid of that memory area. We do

[Devel] Re: [PATCH v4 23/25] memcg: propagate kmem limiting information to children

(2012/06/18 21:43), Glauber Costa wrote: On 06/18/2012 04:37 PM, Kamezawa Hiroyuki wrote: (2012/06/18 19:28), Glauber Costa wrote: The current memcg slab cache management fails to present satisfatory hierarchical behavior in the following scenario: - /cgroups/memory/A/B/C * kmem limit

[Devel] Re: [PATCH v3 00/28] kmem limitation for memcg

(2012/06/07 23:00), Frederic Weisbecker wrote: On Thu, Jun 07, 2012 at 02:53:07PM +0400, Glauber Costa wrote: On 06/07/2012 02:26 PM, Frederic Weisbecker wrote: On Fri, May 25, 2012 at 05:03:20PM +0400, Glauber Costa wrote: Hello All, This is my new take for the memcg kmem accounting. This

[Devel] Re: [PATCH v5 2/2] decrement static keys on real destroy time

(2012/05/17 18:52), Glauber Costa wrote: On 05/17/2012 09:37 AM, Andrew Morton wrote: If that happens, locking in static_key_slow_inc will prevent any damage. My previous version had explicit code to prevent that, but we were pointed out that this is already part of the static_key

[Devel] Re: [PATCH v5 2/2] decrement static keys on real destroy time

(2012/05/17 19:22), Glauber Costa wrote: On 05/17/2012 02:18 PM, KAMEZAWA Hiroyuki wrote: (2012/05/17 18:52), Glauber Costa wrote: On 05/17/2012 09:37 AM, Andrew Morton wrote: If that happens, locking in static_key_slow_inc will prevent any damage. My previous version had explicit

[Devel] Re: [PATCH v2 19/29] skip memcg kmem allocations in specified code regions

(2012/05/16 15:19), Glauber Costa wrote: On 05/15/2012 06:46 AM, KAMEZAWA Hiroyuki wrote: (2012/05/12 2:44), Glauber Costa wrote: This patch creates a mechanism that skip memcg allocations during certain pieces of our core code. It basically works in the same way as preempt_disable

[Devel] Re: [PATCH v2 18/29] memcg: kmem controller charge/uncharge infrastructure

(2012/05/16 15:42), Glauber Costa wrote: On 05/15/2012 06:57 AM, KAMEZAWA Hiroyuki wrote: +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM +int memcg_charge_kmem(struct mem_cgroup *memcg, gfp_t gfp, s64 delta) +{ + struct res_counter *fail_res; + struct mem_cgroup *_memcg; + int may_oom, ret

[Devel] Re: [PATCH v5 2/2] decrement static keys on real destroy time

(2012/05/16 16:04), Glauber Costa wrote: On 05/16/2012 10:03 AM, Glauber Costa wrote: BTW, what is the relationship between 1/2 and 2/2 ? Can't do jump label patching inside an interrupt handler. They need to happen when we free the structure, and I was about to add a worker myself when I

[Devel] Re: [PATCH v2 18/29] memcg: kmem controller charge/uncharge infrastructure

(2012/05/16 17:25), Glauber Costa wrote: On 05/16/2012 12:18 PM, KAMEZAWA Hiroyuki wrote: If at this point the memcg hits a NOFAIL allocation worth 2 pages, by the method I am using, the memcg will be at 4M + 4k after the allocation. Charging it to the root memcg will leave it at 4M - 4k

[Devel] Re: [PATCH v5 2/2] decrement static keys on real destroy time

(2012/05/17 6:13), Andrew Morton wrote: On Fri, 11 May 2012 17:11:17 -0300 Glauber Costa glom...@parallels.com wrote: We call the destroy function when a cgroup starts to be removed, such as by a rmdir event. However, because of our reference counters, some objects are still inflight.

[Devel] Re: [PATCH v2 19/29] skip memcg kmem allocations in specified code regions

...@suse.cz CC: Kamezawa Hiroyuki kamezawa.hir...@jp.fujitsu.com CC: Johannes Weiner han...@cmpxchg.org CC: Suleiman Souhlal sulei...@google.com The concept seems okay to me but... --- include/linux/sched.h |1 + mm/memcontrol.c | 25 + 2 files changed, 26

[Devel] Re: [PATCH v2 18/29] memcg: kmem controller charge/uncharge infrastructure

...@suse.cz CC: Kamezawa Hiroyuki kamezawa.hir...@jp.fujitsu.com CC: Johannes Weiner han...@cmpxchg.org CC: Suleiman Souhlal sulei...@google.com --- include/linux/memcontrol.h | 67 init/Kconfig |2 +- mm/memcontrol.c| 379

[Devel] Re: [PATCH v2 11/29] cgroups: ability to stop res charge propagation on bounded ancestor

(2012/05/12 2:44), Glauber Costa wrote: From: Frederic Weisbecker fweis...@gmail.com Moving a task from a cgroup to another may require to substract its resource charge from the old cgroup and add it to the new one. For this to happen, the uncharge/charge propagation can just stop when we

[Devel] Re: [PATCH v5 1/2] Always free struct memcg through schedule_work()

the jump_label_mutex) Signed-off-by: Glauber Costa glom...@parallels.com CC: Tejun Heo t...@kernel.org CC: Li Zefan lize...@huawei.com CC: Kamezawa Hiroyuki kamezawa.hir...@jp.fujitsu.com CC: Johannes Weiner han...@cmpxchg.org CC: Michal Hocko mho...@suse.cz I think we'll need to revisit

[Devel] Re: [PATCH v5 2/2] decrement static keys on real destroy time

free_work ] [v5: got rid of tcp_limit_mutex, now in the static_key interface ] Signed-off-by: Glauber Costa glom...@parallels.com CC: Tejun Heo t...@kernel.org CC: Li Zefan lize...@huawei.com CC: Kamezawa Hiroyuki kamezawa.hir...@jp.fujitsu.com CC: Johannes Weiner han...@cmpxchg.org CC: Michal

[Devel] Re: [PATCH v4 1/3] make jump_labels wait while updates are in place

combination instead of just an atomic should not kill us. Signed-off-by: Glauber Costa glom...@parallels.com CC: Tejun Heo t...@kernel.org CC: Li Zefan lize...@huawei.com CC: Kamezawa Hiroyuki kamezawa.hir...@jp.fujitsu.com CC: Johannes Weiner han...@cmpxchg.org CC: Michal Hocko mho...@suse.cz

[Devel] Re: [PATCH 16/23] slab: provide kmalloc_no_account

(2012/04/25 23:29), Glauber Costa wrote: On 04/24/2012 10:44 PM, KAMEZAWA Hiroyuki wrote: (2012/04/23 8:53), Glauber Costa wrote: Some allocations need to be accounted to the root memcg regardless of their context. One trivial example, is the allocations we do during the memcg slab cache

[Devel] Re: [PATCH v2 5/5] decrement static keys on real destroy time

(2012/04/24 20:41), Glauber Costa wrote: On 04/23/2012 11:40 PM, KAMEZAWA Hiroyuki wrote: (2012/04/24 4:37), Glauber Costa wrote: We call the destroy function when a cgroup starts to be removed, such as by a rmdir event. However, because of our reference counters, some objects are still

[Devel] Re: [PATCH 04/23] memcg: Make it possible to use the stock for more than one page.

(2012/04/21 6:57), Glauber Costa wrote: From: Suleiman Souhlal ssouh...@freebsd.org Signed-off-by: Suleiman Souhlal sulei...@google.com ok, should work enough. Acked-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com ___ Devel mailing list

[Devel] Re: [PATCH 05/23] memcg: Reclaim when more than one page needed.

to COSTLY_ORDER (as page_alloc.c does), stay safe with a cond_resched(), and make sure not to do it if __GFP_NORETRY. Signed-off-by: Suleiman Souhlal sulei...@google.com Hmm, maybe ok. Reviewed-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com --- mm/memcontrol.c | 18

[Devel] Re: [PATCH 07/23] change defines to an enum

(2012/04/21 6:57), 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. Signed-off-by: Glauber Costa glom...@parallels.com CC: Michal Hocko mho...@suse.cz CC: Kamezawa Hiroyuki

[Devel] Re: [PATCH 08/23] don't force return value checking in res_counter_charge_nofail

(2012/04/21 6:57), Glauber Costa wrote: Since we will succeed with the allocation no matter what, there isn't the need to use __must_check with it. It can very well be optional. Signed-off-by: Glauber Costa glom...@parallels.com CC: Kamezawa Hiroyuki kamezawa.hir...@jp.fujitsu.com CC

[Devel] Re: [PATCH 09/23] kmem slab accounting basic infrastructure

-off-by: Glauber Costa glom...@parallels.com CC: Michal Hocko mho...@suse.cz CC: Kamezawa Hiroyuki kamezawa.hir...@jp.fujitsu.com CC: Johannes Weiner han...@cmpxchg.org The code itself seems fine. Reviewed-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com

[Devel] Re: [PATCH 11/23] slub: consider a memcg parameter in kmem_create_cache

, and will release the index for other caches. This index mechanism was developed by Suleiman Souhlal. Signed-off-by: Glauber Costa glom...@parallels.com CC: Christoph Lameter c...@linux.com CC: Pekka Enberg penb...@cs.helsinki.fi CC: Michal Hocko mho...@suse.cz CC: Kamezawa Hiroyuki

[Devel] Re: [PATCH 16/23] slab: provide kmalloc_no_account

Lameter c...@linux.com CC: Pekka Enberg penb...@cs.helsinki.fi CC: Michal Hocko mho...@suse.cz CC: Kamezawa Hiroyuki kamezawa.hir...@jp.fujitsu.com CC: Johannes Weiner han...@cmpxchg.org CC: Suleiman Souhlal sulei...@google.com Seems reasonable. Reviewed-by: KAMEZAWA Hiroyuki kamezawa.hir

[Devel] Re: [PATCH 17/23] kmem controller charge/uncharge infrastructure

(2012/04/24 23:22), Frederic Weisbecker wrote: On Mon, Apr 23, 2012 at 03:25:59PM -0700, David Rientjes wrote: On Sun, 22 Apr 2012, Glauber Costa wrote: +/* + * Return the kmem_cache we're supposed to use for a slab allocation. + * If we are in interrupt context or otherwise have an

[Devel] Re: [PATCH v2 1/5] don't attach a task to a dead cgroup

destruction point and was already marked as dead. Signed-off-by: Glauber Costa glom...@parallels.com CC: Tejun Heo t...@kernel.org CC: Li Zefan lize...@huawei.com CC: Kamezawa Hiroyuki kamezawa.hir...@jp.fujitsu.com Reviewed-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com --- kernel

[Devel] Re: [PATCH v2 3/5] change number_of_cpusets to an atomic

Reviewed-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel

[Devel] Re: [PATCH v2 4/5] don't take cgroup_mutex in destroy()

Zefan lize...@huawei.com CC: Kamezawa Hiroyuki kamezawa.hir...@jp.fujitsu.com CC: Vivek Goyal vgo...@redhat.com --- kernel/cgroup.c |9 - 1 files changed, 4 insertions(+), 5 deletions(-) diff --git a/kernel/cgroup.c b/kernel/cgroup.c index 932c318..976d332 100644 --- a/kernel

[Devel] Re: [PATCH v2 5/5] decrement static keys on real destroy time

...@parallels.com Acked-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com A small request below. snip + * -activated needs to be written after the static_key update. + * This is what guarantees that the socket activation function + * is the last

[Devel] Re: [PATCH 3/3] decrement static keys on real destroy time

(2012/04/20 7:49), Glauber Costa wrote: We call the destroy function when a cgroup starts to be removed, such as by a rmdir event. However, because of our reference counters, some objects are still inflight. Right now, we are decrementing the static_keys at destroy() time, meaning that if

[Devel] Re: [RFC 5/7] use percpu_counters for res_counter usage

(2012/03/30 22:53), Glauber Costa wrote: On 03/30/2012 11:58 AM, KAMEZAWA Hiroyuki wrote: == Now, we do consume 'reserved' usage, we can avoid css_get(), an heavy atomic ops. You may need to move this code as rcu_read_lock() res_counter_charge() if (failure

[Devel] Re: [RFC 0/7] Initial proposal for faster res_counter updates

(2012/03/30 17:04), Glauber Costa wrote: Hi, Here is my take about how we can make res_counter updates faster. Keep in mind this is a bit of a hack intended as a proof of concept. The pros I see with this: * free updates in non-constrained paths. non-constrained paths includes

[Devel] Re: [RFC 5/7] use percpu_counters for res_counter usage

(2012/03/30 17:04), Glauber Costa wrote: This is the bulk of the proposal. Updates to the res_counter are done to the percpu area, if we are inside what we can call the safe zone. The safe zone is whenever we are far enough from the limit to be sure this update won't touch it. It is bigger

[Devel] Re: [RFC 5/7] use percpu_counters for res_counter usage

(2012/03/30 18:33), KAMEZAWA Hiroyuki wrote: (2012/03/30 17:04), Glauber Costa wrote: Hmm this part doesn't seem very good. I don't think for_each_online_cpu() here will not be a way to the final win. Under multiple hierarchy, you may need to call for_each_online_cpu() in each level

[Devel] Re: [PATCH] memcg: Do not open code accesses to res_counter members

code behavior because that's the standard =) Time to fix it, then. Signed-off-by: Glauber Costa glom...@parallels.com Cc: Johannes Weiner han...@cmpxchg.org Cc: Michal Hocko mho...@suse.cz Cc: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com Acked-by: KAMEZAWA Hiroyuki kamezawa.hir

[Devel] Re: [PATCH v2 02/13] memcg: Kernel memory accounting infrastructure.

(2012/03/14 21:29), Glauber Costa wrote: - What happens when a new cgroup created ? mem_cgroup_create() is called =) Heh, jokes apart, I don't really follow here. What exactly do you mean? There shouldn't be anything extremely out of the ordinary. Sorry, too short words. Assume a

[Devel] Re: [PATCH v2 02/13] memcg: Kernel memory accounting infrastructure.

On Sun, 11 Mar 2012 12:12:04 +0400 Glauber Costa glom...@parallels.com wrote: On 03/10/2012 12:39 AM, Suleiman Souhlal wrote: Enabled with CONFIG_CGROUP_MEM_RES_CTLR_KMEM. Adds the following files: - memory.kmem.independent_kmem_limit - memory.kmem.usage_in_bytes -

[Devel] Re: [PATCH v2 03/13] memcg: Uncharge all kmem when deleting a cgroup.

On Fri, 9 Mar 2012 12:39:06 -0800 Suleiman Souhlal ssouh...@freebsd.org wrote: Signed-off-by: Suleiman Souhlal sulei...@google.com --- mm/memcontrol.c | 31 ++- 1 files changed, 30 insertions(+), 1 deletions(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c

[Devel] Re: [PATCH v2 02/13] memcg: Kernel memory accounting infrastructure.

On Tue, 13 Mar 2012 14:37:30 +0400 Glauber Costa glom...@parallels.com wrote: After looking codes, I think we need to think whether independent_kmem_limit is good or not How about adding MEMCG_KMEM_ACCOUNT flag instead of this and use only memcg-res/memcg-memsw rather than adding a

[Devel] Re: [PATCH 04/10] memcg: Introduce __GFP_NOACCOUNT.

On Wed, 29 Feb 2012 11:09:50 -0800 Suleiman Souhlal sulei...@google.com wrote: On Tue, Feb 28, 2012 at 10:00 PM, KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com wrote: On Mon, 27 Feb 2012 14:58:47 -0800 Suleiman Souhlal ssouh...@freebsd.org wrote: This is used to indicate that we don't

[Devel] Re: [PATCH 1/7] small cleanup for memcontrol.c

On Wed, 29 Feb 2012 14:30:35 -0300 Glauber Costa glom...@parallels.com wrote: On 02/22/2012 12:01 PM, Glauber Costa wrote: On 02/22/2012 04:46 AM, KAMEZAWA Hiroyuki wrote: On Tue, 21 Feb 2012 15:34:33 +0400 Glauber Costaglom...@parallels.com wrote: Move some hardcoded definitions

[Devel] Re: [PATCH 04/10] memcg: Introduce __GFP_NOACCOUNT.

On Wed, 29 Feb 2012 21:24:11 -0300 Glauber Costa glom...@parallels.com wrote: On 02/29/2012 09:10 PM, KAMEZAWA Hiroyuki wrote: On Wed, 29 Feb 2012 11:09:50 -0800 Suleiman Souhlalsulei...@google.com wrote: On Tue, Feb 28, 2012 at 10:00 PM, KAMEZAWA Hiroyuki kamezawa.hir

[Devel] Re: [PATCH 08/10] memcg: Add CONFIG_CGROUP_MEM_RES_CTLR_KMEM_ACCT_ROOT.

On Tue, 28 Feb 2012 15:36:27 -0800 Suleiman Souhlal sulei...@google.com wrote: On Tue, Feb 28, 2012 at 5:34 AM, Glauber Costa glom...@parallels.com wrote: On 02/27/2012 07:58 PM, Suleiman Souhlal wrote: This config option dictates whether or not kernel memory in the root cgroup should be

[Devel] Re: [PATCH 04/10] memcg: Introduce __GFP_NOACCOUNT.

On Mon, 27 Feb 2012 14:58:47 -0800 Suleiman Souhlal ssouh...@freebsd.org wrote: This is used to indicate that we don't want an allocation to be accounted to the current cgroup. Signed-off-by: Suleiman Souhlal sulei...@google.com I don't like this. Please add ___GFP_ACCOUNT account this

[Devel] Re: [PATCH 03/10] memcg: Reclaim when more than one page needed.

On Mon, 27 Feb 2012 14:58:46 -0800 Suleiman Souhlal ssouh...@freebsd.org wrote: From: Hugh Dickins hu...@google.com mem_cgroup_do_charge() was written before slab accounting, and expects three cases: being called for 1 page, being called for a stock of 32 pages, or being called for a

[Devel] Re: [PATCH 02/10] memcg: Uncharge all kmem when deleting a cgroup.

On Mon, 27 Feb 2012 14:58:45 -0800 Suleiman Souhlal ssouh...@freebsd.org wrote: A later patch will also use this to move the accounting to the root cgroup. Signed-off-by: Suleiman Souhlal sulei...@google.com --- mm/memcontrol.c | 30 +- 1 files changed, 29

[Devel] Re: [PATCH 1/7] small cleanup for memcontrol.c

...@redhat.com CC: Michal Hocko mho...@suse.cz CC: Hiroyouki Kamezawa kamezawa.hir...@jp.fujitsu.com CC: Paul Turner p...@google.com CC: Frederic Weisbecker fweis...@gmail.com seems ok to me. Acked-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com a nitpick.. --- mm/memcontrol.c | 10

[Devel] Re: [PATCH 3/7] per-cgroup slab caches

On Tue, 21 Feb 2012 15:34:35 +0400 Glauber Costa glom...@parallels.com wrote: This patch creates the infrastructure to allow us to register per-memcg slab caches. As an example implementation, I am tracking the dentry cache, but others will follow. I am using an opt-in istead of opt-out

[Devel] Re: [PATCH 4/7] chained slab caches: move pages to a different cache when a cache is destroyed.

On Tue, 21 Feb 2012 15:34:36 +0400 Glauber Costa glom...@parallels.com wrote: In the context of tracking kernel memory objects to a cgroup, the following problem appears: we may need to destroy a cgroup, but this does not guarantee that all objects inside the cache are dead. This can't be

[Devel] Re: [PATCH 5/7] shrink support for memcg kmem controller

On Tue, 21 Feb 2012 15:34:37 +0400 Glauber Costa glom...@parallels.com wrote: This patch adds the shrinker interface to memcg proposed kmem controller. With this, softlimits starts being meaningful. I didn't played to much with softlimits itself, since it is a bit in progress for the general

[Devel] Re: [PATCH v9 0/9] Request for inclusion: per-cgroup tcp memory pressure controls

On Mon, 12 Dec 2011 11:47:00 +0400 Glauber Costa glom...@parallels.com wrote: Hi, This series fixes all the few comments raised in the last round, and seem to have acquired consensus from the memcg side. Dave, do you think it is acceptable now from the networking PoV? In case positive,

[Devel] Re: How to draw values for /proc/stat

On Sun, 11 Dec 2011 15:50:56 +0100 Glauber Costa glom...@parallels.com wrote: On 12/09/2011 03:55 PM, Glauber Costa wrote: On 12/09/2011 12:03 PM, Peter Zijlstra wrote: On Mon, 2011-12-05 at 07:32 -0200, Glauber Costa wrote: Hi, Specially Peter and Paul, but all the others: As you

[Devel] Re: [PATCH v8 3/9] socket: initial cgroup code.

On Fri, 9 Dec 2011 10:43:00 -0200 Glauber Costa glom...@parallels.com wrote: On 12/09/2011 12:05 AM, KAMEZAWA Hiroyuki wrote: On Mon, 5 Dec 2011 19:34:57 -0200 Glauber Costaglom...@parallels.com wrote: The goal of this work is to move the memory pressure tcp controls to a cgroup

[Devel] Re: [PATCH v8 1/9] Basic kernel memory functionality for the Memory Controller

On Fri, 9 Dec 2011 12:37:23 -0200 Glauber Costa glom...@parallels.com wrote: On 12/08/2011 11:21 PM, KAMEZAWA Hiroyuki wrote: Hm, why you check val != parent-kmem_independent_accounting ? if (parent parent-use_hierarchy) return -EINVAL; ? BTW, you didn't check

[Devel] Re: [PATCH v8 2/9] foundations of per-cgroup memory pressure controlling.

kamezawa.hir...@jp.fujitsu.com CC: Eric W. Biederman ebied...@xmission.com CC: Eric Dumazet eric.duma...@gmail.com please get ack from network guys. from me. Reviewed-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com ___ Devel mailing list Devel

[Devel] Re: [PATCH v8 3/9] socket: initial cgroup code.

nothing tcp-specific. Signed-off-by: Glauber Costa glom...@parallels.com CC: Kirill A. Shutemov kir...@shutemov.name CC: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujtsu.com CC: David S. Miller da...@davemloft.net CC: Eric W. Biederman ebied...@xmission.com CC: Eric Dumazet eric.duma...@gmail.com

[Devel] Re: [PATCH v8 4/9] tcp memory pressure controls

-by: Glauber Costa glom...@parallels.com CC: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujtisu.com CC: Eric W. Biederman ebied...@xmission.com Reviewed-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com ___ Devel mailing list Devel@openvz.org https

[Devel] Re: [PATCH v8 5/9] per-netns ipv4 sysctl_tcp_mem

in the patches that follows in this patchset. Signed-off-by: Glauber Costa glom...@parallels.com CC: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com CC: David S. Miller da...@davemloft.net CC: Eric W. Biederman ebied...@xmission.com Reviewed-by: KAMEZAWA Hiroyuki kamezawa.hir

[Devel] Re: [PATCH v8 6/9] tcp buffer limitation: per-cgroup limit

...@parallels.com CC: David S. Miller da...@davemloft.net CC: Hiroyouki Kamezawa kamezawa.hir...@jp.fujitsu.com CC: Eric W. Biederman ebied...@xmission.com Reviewed-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com ___ Devel mailing list Devel@openvz.org https

[Devel] Re: [PATCH v8 7/9] Display current tcp memory allocation in kmem cgroup

-by: Glauber Costa glom...@parallels.com Reviewed-by: Hiroyouki Kamezawa kamezawa.hir...@jp.fujitsu.com CC: David S. Miller da...@davemloft.net CC: Eric W. Biederman ebied...@xmission.com Reviewed-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com

[Devel] Re: [PATCH v8 9/9] Display maximum tcp memory allocation in kmem cgroup

. Biederman ebied...@xmission.com Reviewed-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel

[Devel] Re: [PATCH v8 3/9] socket: initial cgroup code.

nothing tcp-specific. Signed-off-by: Glauber Costa glom...@parallels.com CC: Kirill A. Shutemov kir...@shutemov.name CC: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujtsu.com CC: David S. Miller da...@davemloft.net CC: Eric W. Biederman ebied...@xmission.com CC: Eric Dumazet eric.duma...@gmail.com

[Devel] Re: [PATCH v7 00/10] Request for Inclusion: per-cgroup tcp memory pressure

On Mon, 5 Dec 2011 07:09:51 -0200 Glauber Costa glom...@parallels.com wrote: On 12/05/2011 12:06 AM, KAMEZAWA Hiroyuki wrote: On Fri, 2 Dec 2011 16:04:08 -0200 Glauber Costaglom...@parallels.com wrote: On 11/30/2011 12:11 AM, KAMEZAWA Hiroyuki wrote: On Tue, 29 Nov 2011 21:56:51 -0200

[Devel] Re: How to draw values for /proc/stat

On Mon, 5 Dec 2011 07:32:33 -0200 Glauber Costa glom...@parallels.com wrote: Hi, Specially Peter and Paul, but all the others: As you can see in https://lkml.org/lkml/2011/12/4/178, and in my answer to that, there is a question - one I've asked before but without that much of an

[Devel] Re: [PATCH v7 02/10] foundations of per-cgroup memory pressure controlling.

On Fri, 2 Dec 2011 15:46:46 -0200 Glauber Costa glom...@parallels.com wrote: static void proto_seq_printf(struct seq_file *seq, struct proto *proto) { + struct mem_cgroup *memcg = mem_cgroup_from_task(current); + seq_printf(seq, %-9s %4u %6d %6ld %-3s %6u %-3s %-10s

[Devel] Re: [PATCH v7 04/10] tcp memory pressure controls

On Fri, 2 Dec 2011 15:57:28 -0200 Glauber Costa glom...@parallels.com wrote: On 11/29/2011 11:49 PM, KAMEZAWA Hiroyuki wrote: -static struct mem_cgroup *mem_cgroup_from_cont(struct cgroup *cont) +struct mem_cgroup *mem_cgroup_from_cont(struct cgroup *cont) { return container_of

  1   2   3   4   5   6   7   8   >