From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
To: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
Cc: linux-mm <linux-mm@kvack.org>,
Balbir Singh <balbir@linux.vnet.ibm.com>,
Li Zefan <lizf@cn.fujitsu.com>
Subject: Re: [RFC][BUGFIX] memcg: rmdir doesn't return
Date: Mon, 15 Jun 2009 12:02:13 +0900 [thread overview]
Message-ID: <20090615120213.e9a3bd1d.kamezawa.hiroyu@jp.fujitsu.com> (raw)
In-Reply-To: <20090615115021.c79444cb.nishimura@mxp.nes.nec.co.jp>
On Mon, 15 Jun 2009 11:50:21 +0900
Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp> wrote:
> > Then, my suggestion is here.
> > ==
> > } else {
> > ent.val = page_private(page);
> > id = lookup_swap_cgroup(ent);
> > rcu_read_lock();
> > mem = mem_cgroup_lookup(id);
> > if (mem) {
> > if (css_tryget(mem->css)) {
> > /*
> > * If no processes in this cgroup, accounting back to
> > * this cgroup seems silly and prevents RMDIR.
> > */
> > struct cgroup *cg = mem->css.cgroup;
> > if (!atomic_read(&cg->count) && list_empty(&cg->children)) {
> > css_put(&mem->css);
> > mem = NULL;
> > }
> > }
> > rcu_read_unlock();
> > }
> > ==
> >
> Thank you for your suggestion.
> To be honest, I think swap cache behavior would be complicated anyway :(
>
> I prefer my change because the behavior would become consistent with
> the case we don't use mem+swap controller and with the behavior of page cache.
>
I don't like implict resource move. I'll try some today. plz see it.
_But_ this case just happens when swap is shared between cgroups and _very_ heavy
swap-in continues very long. I don't think this is a fatal and BUG.
But ok, maybe wake-up path is not enough.
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>
next prev parent reply other threads:[~2009-06-15 3:03 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-12 5:33 Daisuke Nishimura
2009-06-12 6:19 ` KAMEZAWA Hiroyuki
2009-06-15 2:50 ` Daisuke Nishimura
2009-06-15 3:02 ` KAMEZAWA Hiroyuki [this message]
2009-06-15 8:17 ` KAMEZAWA Hiroyuki
2009-06-16 2:47 ` Daisuke Nishimura
2009-06-16 5:00 ` KAMEZAWA Hiroyuki
2009-06-16 6:38 ` Daisuke Nishimura
2009-06-16 6:48 ` KAMEZAWA Hiroyuki
2009-06-16 8:44 ` KAMEZAWA Hiroyuki
2009-06-17 4:56 ` Balbir Singh
2009-06-17 5:11 ` KAMEZAWA Hiroyuki
2009-06-17 5:49 ` Balbir Singh
2009-06-17 6:27 ` KAMEZAWA Hiroyuki
2009-06-17 7:35 ` Balbir Singh
2009-06-17 9:05 ` KAMEZAWA Hiroyuki
2009-06-17 9:24 ` Balbir Singh
2009-06-18 3:03 ` Daisuke Nishimura
2009-06-18 3:21 ` 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=20090615120213.e9a3bd1d.kamezawa.hiroyu@jp.fujitsu.com \
--to=kamezawa.hiroyu@jp.fujitsu.com \
--cc=balbir@linux.vnet.ibm.com \
--cc=linux-mm@kvack.org \
--cc=lizf@cn.fujitsu.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