Messages in this thread | | | Date | Wed, 14 Jan 2009 12:00:44 +0900 | From | KAMEZAWA Hiroyuki <> | Subject | Re: [RFC][PATCH 4/4] cgroup-memcg fix frequent EBUSY at rmdir |
| |
On Tue, 13 Jan 2009 18:48:43 -0800 Paul Menage <menage@google.com> wrote:
> On Thu, Jan 8, 2009 at 1:35 AM, KAMEZAWA Hiroyuki > <kamezawa.hiroyu@jp.fujitsu.com> wrote: > > + if (ret == -EAGAIN) { /* subsys asks us to retry later */ > > + mutex_unlock(&cgroup_mutex); > > + cond_resched(); > > + goto retry; > > + } > > This spinning worries me a bit. It might be better to do an > interruptible sleep until the relevant CSS's refcount goes down to > zero.
Hmm, add wait_queue to css and wake it up at css_put() ?
like this ? == __css_put() { if (atomi_dec_return(&css->refcnt) == 1) { if (notify_on_release(cgrp) { ..... } if (someone_waiting_rmdir(css)) { wake_up_him(). } } } ==
> And is there no way that the memory controller can hang on to a > reference indefinitely, if the cgroup still has some pages charged to > it? > pre_destroy() is for that. Now, If there are still references from "page" after pre_destroy(), it's bug. swap-in after pre_destory() may add new refs from pages. (I implemented reference from "swap" to be memcg internal refcnt not to css.)
Allowing Ctrl-C/alarm() here by signal_pending() will be better, anyway.
Thanks, -Kame
| |