lkml.org 
[lkml]   [2010]   [Feb]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/2] memcg: dirty pages accounting and limiting infrastructure
Hi,

On Fri, 26 Feb 2010 13:50:04 +0900
Minchan Kim <minchan.kim@gmail.com> wrote:

> > Hm ? I don't read the whole thread but can_attach() is called under
> > cgroup_mutex(). So, it doesn't need to use RCU.
>
> Vivek mentioned memcg is protected by RCU if I understand his intention right.
> So I commented that without enough knowledge of memcg.
> After your comment, I dive into the code.
>
> Just out of curiosity.
>
> Really, memcg is protected by RCU?
yes. All cgroup subsystem is protected by RCU.

> I think most of RCU around memcg is for protecting task_struct and
> cgroup_subsys_state.
> The memcg is protected by cgroup_mutex as you mentioned.
> Am I missing something?

There are several levels of protections.

cgroup subsystem's ->destroy() call back is finally called by

As this.

768 synchronize_rcu();
769
770 mutex_lock(&cgroup_mutex);
771 /*
772 * Release the subsystem state objects.
773 */
774 for_each_subsys(cgrp->root, ss)
775 ss->destroy(ss, cgrp);
776
777 cgrp->root->number_of_cgroups--;
778 mutex_unlock(&cgroup_mutex);

Before here,
- there are no tasks under this cgroup (cgroup's refcnt is 0)
&& cgroup is marked as REMOVED.

Then, this access
rcu_read_lock();
mem = mem_cgroup_from_task(task);
if (css_tryget(mem->css)) <===============checks cgroup refcnt
....
rcu_read_unlock()
is O.K.

And, it's graranteed that we don't have to do complicated fine-grain check
if cgroup_mutex() is held.

Because cgroup_mutex() is system-wide heavy lock, this refcnt+RCU trick is
used and works quite well.

Thanks,
-Kame



\
 
 \ /
  Last update: 2010-02-26 06:07    [W:0.067 / U:0.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site