Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754759Ab0IAAex (ORCPT ); Tue, 31 Aug 2010 20:34:53 -0400 Received: from fgwmail6.fujitsu.co.jp ([192.51.44.36]:42644 "EHLO fgwmail6.fujitsu.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751548Ab0IAAew (ORCPT ); Tue, 31 Aug 2010 20:34:52 -0400 X-SecurityPolicyCheck-FJ: OK by FujitsuOutboundMailChecker v1.3.1 Date: Wed, 1 Sep 2010 09:29:48 +0900 From: KAMEZAWA Hiroyuki To: Daisuke Nishimura Cc: linux-mm@kvack.org, "balbir@linux.vnet.ibm.com" , gthelen@google.com, m-ikeda@ds.jp.nec.com, "akpm@linux-foundation.org" , "linux-kernel@vger.kernel.org" , "menage@google.com" , "lizf@cn.fujitsu.com" Subject: Re: [PATCH 2/5] memcg: quick memcg lookup array Message-Id: <20100901092948.a99c6a57.kamezawa.hiroyu@jp.fujitsu.com> In-Reply-To: <20100830170324.16933949.nishimura@mxp.nes.nec.co.jp> References: <20100825170435.15f8eb73.kamezawa.hiroyu@jp.fujitsu.com> <20100825170741.f1f0a220.kamezawa.hiroyu@jp.fujitsu.com> <20100830170324.16933949.nishimura@mxp.nes.nec.co.jp> Organization: FUJITSU Co. LTD. X-Mailer: Sylpheed 3.0.3 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2879 Lines: 91 On Mon, 30 Aug 2010 17:03:24 +0900 Daisuke Nishimura wrote: > > Index: mmotm-0811/mm/memcontrol.c > > =================================================================== > > --- mmotm-0811.orig/mm/memcontrol.c > > +++ mmotm-0811/mm/memcontrol.c > > @@ -195,6 +195,7 @@ static void mem_cgroup_oom_notify(struct > > */ > > struct mem_cgroup { > > struct cgroup_subsys_state css; > > + int valid; /* for checking validness under RCU access.*/ > > /* > > * the counter to account for memory usage > > */ > Do we really need to add this new member ? > Can't we safely access "mem(=rcu_dereference(mem_cgroup[id]))" under rcu_read_lock() ? > (iow, "mem" is not freed ?) > Maybe this can be removed. I'll check again. > > > @@ -4049,6 +4068,7 @@ static void __mem_cgroup_free(struct mem > > mem_cgroup_remove_from_trees(mem); > > free_css_id(&mem_cgroup_subsys, &mem->css); > > > > + atomic_dec(&mem_cgroup_num); > > for_each_node_state(node, N_POSSIBLE) > > free_mem_cgroup_per_zone_info(mem, node); > > > > @@ -4059,6 +4079,19 @@ static void __mem_cgroup_free(struct mem > > vfree(mem); > > } > > > > +static void mem_cgroup_free(struct mem_cgroup *mem) > > +{ > > + /* No more lookup */ > > + mem->valid = 0; > > + rcu_assign_pointer(mem_cgroups[css_id(&mem->css)], NULL); > > + /* > > + * Because we call vfree() etc...use synchronize_rcu() rather than > > + * call_rcu(); > > + */ > > + synchronize_rcu(); > > + __mem_cgroup_free(mem); > > +} > > + > > static void mem_cgroup_get(struct mem_cgroup *mem) > > { > > atomic_inc(&mem->refcnt); > > @@ -4068,7 +4101,7 @@ static void __mem_cgroup_put(struct mem_ > > { > > if (atomic_sub_and_test(count, &mem->refcnt)) { > > struct mem_cgroup *parent = parent_mem_cgroup(mem); > > - __mem_cgroup_free(mem); > > + mem_cgroup_free(mem); > > if (parent) > > mem_cgroup_put(parent); > > } > > @@ -4189,9 +4222,11 @@ mem_cgroup_create(struct cgroup_subsys * > > atomic_set(&mem->refcnt, 1); > > mem->move_charge_at_immigrate = 0; > > mutex_init(&mem->thresholds_lock); > > + atomic_inc(&mem_cgroup_num); > > + register_memcg_id(mem); > > return &mem->css; > > free_out: > > - __mem_cgroup_free(mem); > > + mem_cgroup_free(mem); > > root_mem_cgroup = NULL; > > return ERR_PTR(error); > > } > I think mem_cgroup_num should be increased at mem_cgroup_alloc(), because it > is decreased at __mem_cgroup_free(). Otherwise, it can be decreased while it > has not been increased, if mem_cgroup_create() fails after mem_cgroup_alloc(). > Hmm. thank you for checking, I'll fix. Thanks, -Kame -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/