[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALdu-PCosvJ-SfVROLLM29RoMfxxRyW9E-_Za9A7LTAZwmkPeg@mail.gmail.com>
Date: Tue, 6 Sep 2011 22:24:07 -0700
From: Paul Menage <paul@...lmenage.org>
To: Glauber Costa <glommer@...allels.com>
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 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.
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?
> +
> +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?
Paul
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists