From mboxrd@z Thu Jan 1 00:00:00 1970 From: Frederic Weisbecker Subject: Re: [PATCH v3 16/28] memcg: kmem controller charge/uncharge infrastructure Date: Wed, 30 May 2012 15:11:01 +0200 Message-ID: <20120530131059.GE25094@somewhere.redhat.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> <4FC614CF.5000906@parallels.com> Mime-Version: 1.0 Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=1r+5oBr+buId+pwuIZBXIzqZq9k3H12NR7Kgrt9h5Dw=; b=ixrebmwudcK3abdsbGl6n5SCyZ2TQESsNABHd9u7jhedfTzs0UqfpgSN5aW9IbaXwi WZD4nR8Mo/fDQTWiv0KNK1LTmQRo0Aap10O4OLcBE+QLYOPCLJfePyJSlIvCxFv33YOb 8lZUfFpoNmMc0WZAvFg+1iZZcdb4KDhQoInRfIBBBiEXRvv2Y+CFBbI4rPNtdZyCXHPf c3filorRf2LHjcrH9lKsQHAHPoVpgWcDCvHRVxTzt+YbAvEszar5c7YyxbejYwndCxrV VTlpz2odEYTvc6d4G10AN4enDqm4vQQ7x9NsX///qJA43rAAguPGOk0vrwGzMew9UFn0 s2Pg== Content-Disposition: inline In-Reply-To: <4FC614CF.5000906-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> Sender: cgroups-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Glauber Costa 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 Wed, May 30, 2012 at 04:38:39PM +0400, Glauber Costa wrote: > On 05/30/2012 04:34 PM, Frederic Weisbecker wrote: > >On Fri, May 25, 2012 at 05:03:36PM +0400, Glauber Costa wrote: > >>+bool __mem_cgroup_new_kmem_page(struct page *page, gfp_t gfp) > >>+{ > >>+ struct mem_cgroup *memcg; > >>+ struct page_cgroup *pc; > >>+ bool ret = true; > >>+ size_t size; > >>+ struct task_struct *p; > >>+ > >>+ if (!current->mm || in_interrupt()) > >>+ return true; > >>+ > >>+ rcu_read_lock(); > >>+ p = rcu_dereference(current->mm->owner); > >>+ memcg = mem_cgroup_from_task(p); > > > >So this takes the memcg of the group owner rather than the > >task? I understand why we want this for user memory, but for > >kernel? > > That was already discussed when this first came up in my last submission > If I recall correctly, Kame pointed out that this would be needed > for proper OOM-scoring and killing. Can we have at least a comment in the code that explain the reasons of taking the owner rather than the task? It's not going to be very obvious to future reviewers. > Now of course we won't oom kernel threads or anything like that. Seems we are not even accounting them anyway. > But since this is also accounted towards memcg, it should at least be > consistent with each memcg it accounts to. > > We can't account kmem for the thread's memcg, and mem to the process'. Don't know. This goes a bit against cgroups semantics which group at the task level and not process. But I personally don't mind much, as long as it's documented. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx102.postini.com [74.125.245.102]) by kanga.kvack.org (Postfix) with SMTP id 798936B0062 for ; Wed, 30 May 2012 09:11:08 -0400 (EDT) Received: by vbbey12 with SMTP id ey12so4232398vbb.14 for ; Wed, 30 May 2012 06:11:07 -0700 (PDT) Date: Wed, 30 May 2012 15:11:01 +0200 From: Frederic Weisbecker Subject: Re: [PATCH v3 16/28] memcg: kmem controller charge/uncharge infrastructure Message-ID: <20120530131059.GE25094@somewhere.redhat.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> <4FC614CF.5000906@parallels.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FC614CF.5000906@parallels.com> Sender: owner-linux-mm@kvack.org List-ID: To: Glauber Costa 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 Wed, May 30, 2012 at 04:38:39PM +0400, Glauber Costa wrote: > On 05/30/2012 04:34 PM, Frederic Weisbecker wrote: > >On Fri, May 25, 2012 at 05:03:36PM +0400, Glauber Costa wrote: > >>+bool __mem_cgroup_new_kmem_page(struct page *page, gfp_t gfp) > >>+{ > >>+ struct mem_cgroup *memcg; > >>+ struct page_cgroup *pc; > >>+ bool ret = true; > >>+ size_t size; > >>+ struct task_struct *p; > >>+ > >>+ if (!current->mm || in_interrupt()) > >>+ return true; > >>+ > >>+ rcu_read_lock(); > >>+ p = rcu_dereference(current->mm->owner); > >>+ memcg = mem_cgroup_from_task(p); > > > >So this takes the memcg of the group owner rather than the > >task? I understand why we want this for user memory, but for > >kernel? > > That was already discussed when this first came up in my last submission > If I recall correctly, Kame pointed out that this would be needed > for proper OOM-scoring and killing. Can we have at least a comment in the code that explain the reasons of taking the owner rather than the task? It's not going to be very obvious to future reviewers. > Now of course we won't oom kernel threads or anything like that. Seems we are not even accounting them anyway. > But since this is also accounted towards memcg, it should at least be > consistent with each memcg it accounts to. > > We can't account kmem for the thread's memcg, and mem to the process'. Don't know. This goes a bit against cgroups semantics which group at the task level and not process. But I personally don't mind much, as long as it's documented. -- 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 S1754048Ab2E3NLK (ORCPT ); Wed, 30 May 2012 09:11:10 -0400 Received: from mail-vb0-f46.google.com ([209.85.212.46]:61443 "EHLO mail-vb0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752923Ab2E3NLI (ORCPT ); Wed, 30 May 2012 09:11:08 -0400 Date: Wed, 30 May 2012 15:11:01 +0200 From: Frederic Weisbecker To: Glauber Costa 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 Subject: Re: [PATCH v3 16/28] memcg: kmem controller charge/uncharge infrastructure Message-ID: <20120530131059.GE25094@somewhere.redhat.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> <4FC614CF.5000906@parallels.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FC614CF.5000906@parallels.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 30, 2012 at 04:38:39PM +0400, Glauber Costa wrote: > On 05/30/2012 04:34 PM, Frederic Weisbecker wrote: > >On Fri, May 25, 2012 at 05:03:36PM +0400, Glauber Costa wrote: > >>+bool __mem_cgroup_new_kmem_page(struct page *page, gfp_t gfp) > >>+{ > >>+ struct mem_cgroup *memcg; > >>+ struct page_cgroup *pc; > >>+ bool ret = true; > >>+ size_t size; > >>+ struct task_struct *p; > >>+ > >>+ if (!current->mm || in_interrupt()) > >>+ return true; > >>+ > >>+ rcu_read_lock(); > >>+ p = rcu_dereference(current->mm->owner); > >>+ memcg = mem_cgroup_from_task(p); > > > >So this takes the memcg of the group owner rather than the > >task? I understand why we want this for user memory, but for > >kernel? > > That was already discussed when this first came up in my last submission > If I recall correctly, Kame pointed out that this would be needed > for proper OOM-scoring and killing. Can we have at least a comment in the code that explain the reasons of taking the owner rather than the task? It's not going to be very obvious to future reviewers. > Now of course we won't oom kernel threads or anything like that. Seems we are not even accounting them anyway. > But since this is also accounted towards memcg, it should at least be > consistent with each memcg it accounts to. > > We can't account kmem for the thread's memcg, and mem to the process'. Don't know. This goes a bit against cgroups semantics which group at the task level and not process. But I personally don't mind much, as long as it's documented.