Hello, Glauber.
On Thu, Nov 15, 2012 at 07:00:11AM +0400, Glauber Costa wrote:
> > Ooh, yeah, hmmm... that should happen after this series gets merged.
> > I'll mark it as pending.
> >
> Btw: I did this because there is no other facility to figure out a
> memcg's "name".
>
> I wonder if there is
On 11/14/2012 10:55 PM, Tejun Heo wrote:
> Hello, Glauber.
>
> On Wed, Nov 14, 2012 at 03:05:46PM +0400, Glauber Costa wrote:
>> Will memcontrol.c need similar amendments?
>>
>> The code that lives in -mm and includes kmemcg includes the following
>> excerpt:
>>
>> rcu_read_lock();
>>
Hello, Glauber.
On Wed, Nov 14, 2012 at 03:05:46PM +0400, Glauber Costa wrote:
> Will memcontrol.c need similar amendments?
>
> The code that lives in -mm and includes kmemcg includes the following
> excerpt:
>
> rcu_read_lock();
> dentry = rcu_dereference(memcg->css.cgroup->dent
On 11/13/2012 07:01 AM, Tejun Heo wrote:
> cgroup->dentry is marked and used as a RCU pointer; however, it isn't
> one - the final dentry put doesn't go through call_rcu(). cgroup and
> dentry share the same RCU freeing rule via synchronize_rcu() in
> cgroup_diput() (kfree_rcu() used on cgrp is un
cgroup->dentry is marked and used as a RCU pointer; however, it isn't
one - the final dentry put doesn't go through call_rcu(). cgroup and
dentry share the same RCU freeing rule via synchronize_rcu() in
cgroup_diput() (kfree_rcu() used on cgrp is unnecessary). If cgrp is
accessible under RCU read
5 matches
Mail list logo