From: Vivek Goyal <vgoyal@redhat.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
"nishimura@mxp.nes.nec.co.jp" <nishimura@mxp.nes.nec.co.jp>,
"balbir@linux.vnet.ibm.com" <balbir@linux.vnet.ibm.com>,
gthelen@google.com, m-ikeda@ds.jp.nec.com,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC][PATCH 2/7][memcg] cgroup arbitarary ID allocation
Date: Tue, 27 Jul 2010 23:10:49 -0400 [thread overview]
Message-ID: <20100728031049.GF12642@redhat.com> (raw)
In-Reply-To: <20100728113529.f086716d.kamezawa.hiroyu@jp.fujitsu.com>
On Wed, Jul 28, 2010 at 11:35:29AM +0900, KAMEZAWA Hiroyuki wrote:
> On Tue, 27 Jul 2010 22:30:27 -0400
> Vivek Goyal <vgoyal@redhat.com> wrote:
>
> > > Index: mmotm-2.6.35-0719/Documentation/cgroups/cgroups.txt
> > > ===================================================================
> > > --- mmotm-2.6.35-0719.orig/Documentation/cgroups/cgroups.txt
> > > +++ mmotm-2.6.35-0719/Documentation/cgroups/cgroups.txt
> > > @@ -621,6 +621,15 @@ and root cgroup. Currently this will onl
> > > the default hierarchy (which never has sub-cgroups) and a hierarchy
> > > that is being created/destroyed (and hence has no sub-cgroups).
> > >
> > > +void custom_id(struct cgroup_subsys *ss, struct cgroup *cgrp)
> > > +
> > > +Called at assigning a new ID to cgroup subsystem state struct. This
> > > +is called when ss->use_id == true. If this function is not provided,
> > > +a new ID is automatically assigned. If you enable ss->use_id,
> > > +you can use css_lookup() and css_get_next() to access "css" objects
> > > +via IDs.
> > > +
> >
> > Couple of lines to explain why a subsystem would like to assign its
> > own ids and not be happy with generic cgroup assigned id be helpful.
> > In this case, I think you are using this id as index into array
> > and want to control the index, hence you seem to be doing it.
> >
> > But I am not sure again why do you want to control index?
> >
>
> Now, the subsystem allocation/id-allocation order is
>
> ->create()
> alloc_id.
>
> Otherwise "id" of memory cgroup is just determined by the place in virtual-indexed
> array.
> As
> memcg = mem_cgroup_base + id
>
> This "id" is determined at create().
>
> If "id" is determined regardless of memory cgroup's placement, it's of no use.
> My original design of css_id() allocates id in create() but it was moved to
> generic part. So, this is expected change in my plan.
>
> We have 2 choices.
> id = alloc_id()
> create(id)
> or
> this patch.
>
> Both are okay for me. But alloc id before create() may add some ugly rollback.
Ok, so in current design at the time of mem_cgroup instantiation css_id
is not available so you don't know at what index to put the newly
instantiated mem_cgroup object, hence the notion of let subsys decide
the css_id and cgroup can query from subsystem later.
I don't have any preference. Anything simple works..
Vivek
WARNING: multiple messages have this Message-ID (diff)
From: Vivek Goyal <vgoyal@redhat.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
"nishimura@mxp.nes.nec.co.jp" <nishimura@mxp.nes.nec.co.jp>,
"balbir@linux.vnet.ibm.com" <balbir@linux.vnet.ibm.com>,
gthelen@google.com, m-ikeda@ds.jp.nec.com,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC][PATCH 2/7][memcg] cgroup arbitarary ID allocation
Date: Tue, 27 Jul 2010 23:10:49 -0400 [thread overview]
Message-ID: <20100728031049.GF12642@redhat.com> (raw)
In-Reply-To: <20100728113529.f086716d.kamezawa.hiroyu@jp.fujitsu.com>
On Wed, Jul 28, 2010 at 11:35:29AM +0900, KAMEZAWA Hiroyuki wrote:
> On Tue, 27 Jul 2010 22:30:27 -0400
> Vivek Goyal <vgoyal@redhat.com> wrote:
>
> > > Index: mmotm-2.6.35-0719/Documentation/cgroups/cgroups.txt
> > > ===================================================================
> > > --- mmotm-2.6.35-0719.orig/Documentation/cgroups/cgroups.txt
> > > +++ mmotm-2.6.35-0719/Documentation/cgroups/cgroups.txt
> > > @@ -621,6 +621,15 @@ and root cgroup. Currently this will onl
> > > the default hierarchy (which never has sub-cgroups) and a hierarchy
> > > that is being created/destroyed (and hence has no sub-cgroups).
> > >
> > > +void custom_id(struct cgroup_subsys *ss, struct cgroup *cgrp)
> > > +
> > > +Called at assigning a new ID to cgroup subsystem state struct. This
> > > +is called when ss->use_id == true. If this function is not provided,
> > > +a new ID is automatically assigned. If you enable ss->use_id,
> > > +you can use css_lookup() and css_get_next() to access "css" objects
> > > +via IDs.
> > > +
> >
> > Couple of lines to explain why a subsystem would like to assign its
> > own ids and not be happy with generic cgroup assigned id be helpful.
> > In this case, I think you are using this id as index into array
> > and want to control the index, hence you seem to be doing it.
> >
> > But I am not sure again why do you want to control index?
> >
>
> Now, the subsystem allocation/id-allocation order is
>
> ->create()
> alloc_id.
>
> Otherwise "id" of memory cgroup is just determined by the place in virtual-indexed
> array.
> As
> memcg = mem_cgroup_base + id
>
> This "id" is determined at create().
>
> If "id" is determined regardless of memory cgroup's placement, it's of no use.
> My original design of css_id() allocates id in create() but it was moved to
> generic part. So, this is expected change in my plan.
>
> We have 2 choices.
> id = alloc_id()
> create(id)
> or
> this patch.
>
> Both are okay for me. But alloc id before create() may add some ugly rollback.
Ok, so in current design at the time of mem_cgroup instantiation css_id
is not available so you don't know at what index to put the newly
instantiated mem_cgroup object, hence the notion of let subsys decide
the css_id and cgroup can query from subsystem later.
I don't have any preference. Anything simple works..
Vivek
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2010-07-28 3:11 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-27 7:51 [RFC][PATCH 0/7][memcg] towards I/O aware memory cgroup KAMEZAWA Hiroyuki
2010-07-27 7:51 ` KAMEZAWA Hiroyuki
2010-07-27 7:53 ` [RFC][PATCH 1/7][memcg] virtually indexed array library KAMEZAWA Hiroyuki
2010-07-27 7:53 ` KAMEZAWA Hiroyuki
2010-07-27 18:29 ` Jonathan Corbet
2010-07-27 18:29 ` Jonathan Corbet
2010-07-28 0:08 ` KAMEZAWA Hiroyuki
2010-07-28 0:08 ` KAMEZAWA Hiroyuki
2010-07-28 19:45 ` Andrew Morton
2010-07-28 19:45 ` Andrew Morton
2010-07-29 0:32 ` KAMEZAWA Hiroyuki
2010-07-29 0:32 ` KAMEZAWA Hiroyuki
2010-07-29 4:27 ` KAMEZAWA Hiroyuki
2010-07-29 4:27 ` KAMEZAWA Hiroyuki
2010-08-02 18:00 ` Balbir Singh
2010-08-02 18:00 ` Balbir Singh
2010-08-02 23:45 ` KAMEZAWA Hiroyuki
2010-08-02 23:45 ` KAMEZAWA Hiroyuki
2010-07-27 7:54 ` [RFC][PATCH 2/7][memcg] cgroup arbitarary ID allocation KAMEZAWA Hiroyuki
2010-07-27 7:54 ` KAMEZAWA Hiroyuki
2010-07-28 2:30 ` Vivek Goyal
2010-07-28 2:30 ` Vivek Goyal
2010-07-28 2:35 ` KAMEZAWA Hiroyuki
2010-07-28 2:35 ` KAMEZAWA Hiroyuki
2010-07-28 3:10 ` Vivek Goyal [this message]
2010-07-28 3:10 ` Vivek Goyal
2010-08-02 18:04 ` Balbir Singh
2010-08-02 18:04 ` Balbir Singh
2010-08-02 23:45 ` KAMEZAWA Hiroyuki
2010-08-02 23:45 ` KAMEZAWA Hiroyuki
2010-07-27 7:55 ` [RFC][PATCH 3/7][memcg] memcg on virt array for quick access via ID KAMEZAWA Hiroyuki
2010-07-27 7:55 ` KAMEZAWA Hiroyuki
2010-07-27 7:56 ` [RFC][PATCH 4/7][memcg] memcg use ID in page_cgroup KAMEZAWA Hiroyuki
2010-07-27 7:56 ` KAMEZAWA Hiroyuki
2010-07-28 2:39 ` Vivek Goyal
2010-07-28 2:39 ` Vivek Goyal
2010-07-28 2:44 ` KAMEZAWA Hiroyuki
2010-07-28 2:44 ` KAMEZAWA Hiroyuki
2010-07-28 3:13 ` Vivek Goyal
2010-07-28 3:13 ` Vivek Goyal
2010-07-28 3:18 ` KAMEZAWA Hiroyuki
2010-07-28 3:18 ` KAMEZAWA Hiroyuki
2010-07-28 3:21 ` KAMEZAWA Hiroyuki
2010-07-28 3:21 ` KAMEZAWA Hiroyuki
2010-07-28 14:17 ` Vivek Goyal
2010-07-28 14:17 ` Vivek Goyal
2010-07-28 15:43 ` Munehiro Ikeda
2010-07-28 15:43 ` Munehiro Ikeda
2010-07-27 7:59 ` [RFC][PATCH 5/7][memcg] memcg lockless update of file mapped KAMEZAWA Hiroyuki
2010-07-27 7:59 ` KAMEZAWA Hiroyuki
2010-07-28 7:09 ` Greg Thelen
2010-07-28 7:09 ` Greg Thelen
2010-07-28 7:13 ` KAMEZAWA Hiroyuki
2010-07-28 7:13 ` KAMEZAWA Hiroyuki
2010-07-27 8:00 ` [RFC][PATCH 6/7][memcg] generic file status update KAMEZAWA Hiroyuki
2010-07-27 8:00 ` KAMEZAWA Hiroyuki
2010-07-28 7:12 ` Greg Thelen
2010-07-28 7:12 ` Greg Thelen
2010-07-28 7:14 ` KAMEZAWA Hiroyuki
2010-07-28 7:14 ` KAMEZAWA Hiroyuki
2010-07-27 8:02 ` [RFC][PATCH 7/7][memcg] use spin lock instead of bit_spin_lock in page_cgroup KAMEZAWA Hiroyuki
2010-07-27 8:02 ` KAMEZAWA Hiroyuki
2010-07-28 6:16 ` Greg Thelen
2010-07-28 6:16 ` Greg Thelen
2010-07-28 6:20 ` KAMEZAWA Hiroyuki
2010-07-28 6:20 ` KAMEZAWA Hiroyuki
2010-08-02 18:09 ` Balbir Singh
2010-08-02 18:09 ` Balbir Singh
2010-08-02 23:46 ` KAMEZAWA Hiroyuki
2010-08-02 23:46 ` KAMEZAWA Hiroyuki
2010-07-28 0:13 ` [RFC][PATCH 0/7][memcg] towards I/O aware memory cgroup KAMEZAWA Hiroyuki
2010-07-28 0:13 ` KAMEZAWA Hiroyuki
2010-07-28 14:42 ` Balbir Singh
2010-07-28 14:42 ` Balbir Singh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100728031049.GF12642@redhat.com \
--to=vgoyal@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=balbir@linux.vnet.ibm.com \
--cc=gthelen@google.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=m-ikeda@ds.jp.nec.com \
--cc=nishimura@mxp.nes.nec.co.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.