Messages in this thread | ![/](/images/icornerl.gif) | | Date | Thu, 4 Dec 2008 18:43:09 +0900 | From | KAMEZAWA Hiroyuki <> | Subject | Re: [Experimental][PATCH 19/21] memcg-fix-pre-destroy.patch |
| |
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. ==
-Kame
| ![\](/images/icornerr.gif) |