From mboxrd@z Thu Jan 1 00:00:00 1970 From: Glauber Costa Subject: Re: [PATCH v3 16/28] memcg: kmem controller charge/uncharge infrastructure Date: Wed, 30 May 2012 16:38:39 +0400 Message-ID: <4FC614CF.5000906@parallels.com> References: <1337951028-3427-1-git-send-email-glommer@parallels.com> <1337951028-3427-17-git-send-email-glommer@parallels.com> <20120530123406.GC25094@somewhere.redhat.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20120530123406.GC25094-oHC15RC7JGTpAmv0O++HtFaTQe2KTcn/@public.gmane.org> Sender: cgroups-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: Frederic Weisbecker Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org, Tejun Heo , Li Zefan , Greg Thelen , Suleiman Souhlal , Michal Hocko , Johannes Weiner , devel-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org, David Rientjes , Christoph Lameter , Pekka Enberg On 05/30/2012 04:34 PM, Frederic Weisbecker wrote: > On Fri, May 25, 2012 at 05:03:36PM +0400, Glauber Costa wrote: >> +bool __mem_cgroup_new_kmem_page(struct page *page, gfp_t gfp) >> +{ >> + struct mem_cgroup *memcg; >> + struct page_cgroup *pc; >> + bool ret = true; >> + size_t size; >> + struct task_struct *p; >> + >> + if (!current->mm || in_interrupt()) >> + return true; >> + >> + rcu_read_lock(); >> + p = rcu_dereference(current->mm->owner); >> + memcg = mem_cgroup_from_task(p); > > So this takes the memcg of the group owner rather than the > task? I understand why we want this for user memory, but for > kernel? That was already discussed when this first came up in my last submission If I recall correctly, Kame pointed out that this would be needed for proper OOM-scoring and killing. Now of course we won't oom kernel threads or anything like that. But since this is also accounted towards memcg, it should at least be consistent with each memcg it accounts to. We can't account kmem for the thread's memcg, and mem to the process'. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx125.postini.com [74.125.245.125]) by kanga.kvack.org (Postfix) with SMTP id 8AD2F6B005C for ; Wed, 30 May 2012 08:40:59 -0400 (EDT) Message-ID: <4FC614CF.5000906@parallels.com> Date: Wed, 30 May 2012 16:38:39 +0400 From: Glauber Costa MIME-Version: 1.0 Subject: Re: [PATCH v3 16/28] memcg: kmem controller charge/uncharge infrastructure References: <1337951028-3427-1-git-send-email-glommer@parallels.com> <1337951028-3427-17-git-send-email-glommer@parallels.com> <20120530123406.GC25094@somewhere.redhat.com> In-Reply-To: <20120530123406.GC25094@somewhere.redhat.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Frederic Weisbecker Cc: linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org, kamezawa.hiroyu@jp.fujitsu.com, Tejun Heo , Li Zefan , Greg Thelen , Suleiman Souhlal , Michal Hocko , Johannes Weiner , devel@openvz.org, David Rientjes , Christoph Lameter , Pekka Enberg On 05/30/2012 04:34 PM, Frederic Weisbecker wrote: > On Fri, May 25, 2012 at 05:03:36PM +0400, Glauber Costa wrote: >> +bool __mem_cgroup_new_kmem_page(struct page *page, gfp_t gfp) >> +{ >> + struct mem_cgroup *memcg; >> + struct page_cgroup *pc; >> + bool ret = true; >> + size_t size; >> + struct task_struct *p; >> + >> + if (!current->mm || in_interrupt()) >> + return true; >> + >> + rcu_read_lock(); >> + p = rcu_dereference(current->mm->owner); >> + memcg = mem_cgroup_from_task(p); > > So this takes the memcg of the group owner rather than the > task? I understand why we want this for user memory, but for > kernel? That was already discussed when this first came up in my last submission If I recall correctly, Kame pointed out that this would be needed for proper OOM-scoring and killing. Now of course we won't oom kernel threads or anything like that. But since this is also accounted towards memcg, it should at least be consistent with each memcg it accounts to. We can't account kmem for the thread's memcg, and mem to the process'. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753627Ab2E3Mk7 (ORCPT ); Wed, 30 May 2012 08:40:59 -0400 Received: from mx2.parallels.com ([64.131.90.16]:52257 "EHLO mx2.parallels.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753268Ab2E3Mk6 (ORCPT ); Wed, 30 May 2012 08:40:58 -0400 Message-ID: <4FC614CF.5000906@parallels.com> Date: Wed, 30 May 2012 16:38:39 +0400 From: Glauber Costa User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Frederic Weisbecker CC: , , , , Tejun Heo , Li Zefan , Greg Thelen , Suleiman Souhlal , Michal Hocko , Johannes Weiner , , David Rientjes , Christoph Lameter , Pekka Enberg Subject: Re: [PATCH v3 16/28] memcg: kmem controller charge/uncharge infrastructure References: <1337951028-3427-1-git-send-email-glommer@parallels.com> <1337951028-3427-17-git-send-email-glommer@parallels.com> <20120530123406.GC25094@somewhere.redhat.com> In-Reply-To: <20120530123406.GC25094@somewhere.redhat.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/30/2012 04:34 PM, Frederic Weisbecker wrote: > On Fri, May 25, 2012 at 05:03:36PM +0400, Glauber Costa wrote: >> +bool __mem_cgroup_new_kmem_page(struct page *page, gfp_t gfp) >> +{ >> + struct mem_cgroup *memcg; >> + struct page_cgroup *pc; >> + bool ret = true; >> + size_t size; >> + struct task_struct *p; >> + >> + if (!current->mm || in_interrupt()) >> + return true; >> + >> + rcu_read_lock(); >> + p = rcu_dereference(current->mm->owner); >> + memcg = mem_cgroup_from_task(p); > > So this takes the memcg of the group owner rather than the > task? I understand why we want this for user memory, but for > kernel? That was already discussed when this first came up in my last submission If I recall correctly, Kame pointed out that this would be needed for proper OOM-scoring and killing. Now of course we won't oom kernel threads or anything like that. But since this is also accounted towards memcg, it should at least be consistent with each memcg it accounts to. We can't account kmem for the thread's memcg, and mem to the process'.