linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
To: Li Zefan <lizf@cn.fujitsu.com>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
	"menage@google.com" <menage@google.com>,
	"balbir@linux.vnet.ibm.com" <balbir@linux.vnet.ibm.com>,
	"nishimura@mxp.nes.nec.co.jp" <nishimura@mxp.nes.nec.co.jp>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>
Subject: Re: [PATCH 1/3] cgroup: fix pre_destroy and semantics of css->refcnt
Date: Tue, 2 Dec 2008 16:13:46 +0900	[thread overview]
Message-ID: <20081202161346.f86db973.kamezawa.hiroyu@jp.fujitsu.com> (raw)
In-Reply-To: <4934DC34.7090406@cn.fujitsu.com>

On Tue, 02 Dec 2008 14:56:52 +0800
Li Zefan <lizf@cn.fujitsu.com> wrote:

> KAMEZAWA Hiroyuki wrote:
> > On Tue, 02 Dec 2008 14:15:23 +0800
> > Li Zefan <lizf@cn.fujitsu.com> wrote:
> > 
> >> KAMEZAWA Hiroyuki wrote:
> >>> Now, final check of refcnt is done after pre_destroy(), so rmdir() can fail
> >>> after pre_destroy().
> >>> memcg set mem->obsolete to be 1 at pre_destroy and this is buggy..
> >>>
> >>> Several ways to fix this can be considered. This is an idea.
> >>>
> >> I don't see what's the difference with css_under_removal() in this patch and
> >> cgroup_is_removed() which is currently available.
> >>
> >> CGRP_REMOVED flag is set in cgroup_rmdir() when it's confirmed that rmdir can
> >> be sucessfully performed.
> >>
> >> So mem->obsolete can be replaced with:
> >>
> >> bool mem_cgroup_is_obsolete(struct mem_cgroup *mem)
> >> {
> >> 	return cgroup_is_removed(mem->css.cgroup);
> >> }
> >>
> >> Or am I missing something?
> >>
> > Yes.
> > 	1. "cgroup" and "css" object are different object.
> > 	2. css object may not be freed at destroy() (as current memcg does.)
> > 
> > Some of css objects cannot be freed even when there are no tasks because
> > of reference from some persistent object or temporal refcnt.
> > 
> 
> I just noticed mem_cgroup has its own refcnt now. The memcg code has changed
> dramatically that I don't catch up with it. Thx for the explanation.
> 
> But I have another doubt:
> 
> void mem_cgroup_uncharge_swapcache(struct page *page, swp_entry_t ent)
> {
> 	struct mem_cgroup *memcg;
> 
> 	memcg = __mem_cgroup_uncharge_common(page,
> 					MEM_CGROUP_CHARGE_TYPE_SWAPOUT);
> 	/* record memcg information */
> 	if (do_swap_account && memcg) {
> 		swap_cgroup_record(ent, memcg);
> 		mem_cgroup_get(memcg);
> 	}
> }
> 
> In the above code, is it possible that memcg is freed before mem_cgroup_get()
> increases memcg->refcnt?
> 
Thank you for looking into. maybe possible.

In this case, 
	1. "the page" was belongs to memcg before uncharge().
	2. but it's not guaranteed that memcg is alive after uncharge.

OK. maybe css_tryget() can change this to be
==
	rcu_read_lock();
	memcg = __mem_cgroup_uncharge_common(page,
					MEM_CGROUP_CHARGE_TYPE_SWAPOUT);
	if (do_swap_account && memcg && css_tryget(&memcg->css)) {
		swap_cgroup_record(ent, memcg);
		mem_cgroup_get(memcg);
		css_put(&memcg->css);
	}
	rcu_read_unlock();
==
How about this ?


Thanks,
-Kame




--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2008-12-02  7:14 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-01  5:59 [PATCH 0/3] cgroup id and scanning without cgroup_lock KAMEZAWA Hiroyuki
2008-12-01  6:02 ` [PATCH 1/3] cgroup: fix pre_destroy and semantics of css->refcnt KAMEZAWA Hiroyuki
2008-12-02  6:15   ` Li Zefan
2008-12-02  6:21     ` KAMEZAWA Hiroyuki
2008-12-02  6:56       ` Li Zefan
2008-12-02  7:13         ` KAMEZAWA Hiroyuki [this message]
2008-12-02  7:31           ` Li Zefan
2008-12-02  7:39             ` KAMEZAWA Hiroyuki
2008-12-03  3:44   ` Li Zefan
2008-12-03  3:54     ` KAMEZAWA Hiroyuki
2008-12-01  6:03 ` [PATCH 2/3] cgroup: cgroup ID and scanning under RCU KAMEZAWA Hiroyuki
2008-12-01  6:04 ` [PATCH 3/3] memcg: change hierarhcy managenemt to use scan by cgroup ID KAMEZAWA Hiroyuki
2008-12-01  6:24 ` [PATCH 0/3] cgroup id and scanning without cgroup_lock Balbir Singh
2008-12-01  7:52   ` KAMEZAWA Hiroyuki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081202161346.f86db973.kamezawa.hiroyu@jp.fujitsu.com \
    --to=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=akpm@linux-foundation.org \
    --cc=balbir@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lizf@cn.fujitsu.com \
    --cc=menage@google.com \
    --cc=nishimura@mxp.nes.nec.co.jp \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox