[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4E670764.1040805@parallels.com>
Date: Wed, 7 Sep 2011 02:55:48 -0300
From: Glauber Costa <glommer@...allels.com>
To: Paul Menage <paul@...lmenage.org>
CC: <linux-kernel@...r.kernel.org>, <linux-mm@...ck.org>,
<containers@...ts.osdl.org>, <netdev@...r.kernel.org>,
<xemul@...allels.com>, "David S. Miller" <davem@...emloft.net>,
Hiroyouki Kamezawa <kamezawa.hiroyu@...fujitsu.com>,
"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: [PATCH v2 2/9] Kernel Memory cgroup
On 09/07/2011 02:24 AM, Paul Menage wrote:
> On Tue, Sep 6, 2011 at 9:23 PM, Glauber Costa<glommer@...allels.com> wrote:
>> +
>> +struct kmem_cgroup {
>> + struct cgroup_subsys_state css;
>> + struct kmem_cgroup *parent;
>> +};
>
> There's a parent pointer in css.cgroup, so you shouldn't need a
> separate one here.
Ok, I missed that. Thanks
> Most cgroup subsystems define this structure (and the below accessor
> functions) in their .c file rather than exposing it to the world? Does
> this subsystem particularly need it exposed?
Originally I was using it in sock.c and friends. Now, from the last
submission to this one, most of those uses were substituted. The
acessors, however, are in kmem_cgroup.h. Reason being I want most of
them to be inline.
>> +
>> +static struct cgroup_subsys_state *kmem_create(
>> + struct cgroup_subsys *ss, struct cgroup *cgrp)
>> +{
>> + struct kmem_cgroup *sk = kzalloc(sizeof(*sk), GFP_KERNEL);
>
> kcg or just cg would be a better name?
I'll go with kcg.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists