Messages in this thread | | | Date | Thu, 4 Dec 2008 18:49:08 +0900 | From | KAMEZAWA Hiroyuki <> | Subject | Re: [Experimental][PATCH 19/21] memcg-fix-pre-destroy.patch |
| |
On Thu, 4 Dec 2008 18:43:09 +0900 KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> On Thu, 4 Dec 2008 18:34:28 +0900 > Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp> wrote: > > > Added CC: Paul Menage <menage@google.com> > > > > > @@ -2096,7 +2112,7 @@ static void mem_cgroup_get(struct mem_cg > > > static void mem_cgroup_put(struct mem_cgroup *mem) > > > { > > > if (atomic_dec_and_test(&mem->refcnt)) { > > > - if (!mem->obsolete) > > > + if (!css_under_removal(&mem->css)) > > > return; > > > mem_cgroup_free(mem); > > > } > > I don't think it's safe to check css_under_removal here w/o cgroup_lock. > > (It's safe *NOW* just because memcg is the only user of css->refcnt.) > > > > > As Li said before, css_under_removal doesn't necessarily mean > > this this group has been destroyed, but mem_cgroup will be freed. > > > > But adding cgroup_lock/unlock here causes another dead lock, > > because mem_cgroup_get_next_node calls mem_cgroup_put. > > > > hmm.. hierarchical reclaim code will be re-written completely by [21/21], > > so would it be better to change patch order or to take another approach ? > > > Hmm, ok. > > How about this ? > == > At initlization, mem_cgroup_create(), set memcg->refcnt to be 1. > > At destroy(), put this refcnt by 1. > > remove css_under_removal(&mem->css) check. > == Ah, anyway, I'll remove mem->refcnt when swap-cgroup uses this ID. I'll use refcnt-to-ID rather than this.
Thanks, -Kame
| |