From: Li Zefan <lizf@cn.fujitsu.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Paul Menage <menage@google.com>,
akpm@linux-foundation.org, containers@lists.linux-foundation.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/4] Allow cgroup hierarchies to be created with no bound subsystems
Date: Thu, 23 Jul 2009 16:32:17 +0800 [thread overview]
Message-ID: <4A682011.5010400@cn.fujitsu.com> (raw)
In-Reply-To: <20090723171913.3279de8c.kamezawa.hiroyu@jp.fujitsu.com>
>> - /* We can't have an empty hierarchy */
>> +
>> + /* Can't specify "none" and some subsystems */
>> + if (opts->subsys_bits && opts->none)
>> + return -EINVAL;
>
> Is this case never happens ?
>
> BUG_ON(!opts->subsys_bits && !opts->none)
>
It can happen:
# mount -t cgroup -o none,memory
>
>> +
>> + /*
>> + * We either have to specify by name or by subsystems. (So all
>> + * empty hierarchies must have a name).
>> + */
>> if (!opts->subsys_bits && !opts->name)
>> return -EINVAL;
>>
>> @@ -1129,6 +1124,31 @@ static void init_cgroup_root(struct cgroupfs_root *root)
>> init_cgroup_housekeeping(cgrp);
>> }
>>
>> +static bool init_root_id(struct cgroupfs_root *root)
>> +{
>> + int ret = 0;
>> +
>> + do {
>> + if (!ida_pre_get(&hierarchy_ida, GFP_KERNEL))
>> + return false;
>> + spin_lock(&hierarchy_id_lock);
>> + /* Try to allocate the next unused ID */
>> + ret = ida_get_new_above(&hierarchy_ida, next_hierarchy_id,
>> + &root->hierarchy_id);
>
> Why new id should be greater than old one ?
> Just for avoiding reuse-id-too-soon ?
>
Otherwise we can't identify each hierachy by it's id.
>> + if (ret == -ENOSPC)
>> + /* Try again starting from 0 */
>> + ret = ida_get_new(&hierarchy_ida, &root->hierarchy_id);
>> + if (!ret) {
>> + next_hierarchy_id = root->hierarchy_id + 1;
>> + } else if (ret != -EAGAIN) {
>> + /* Can only get here if the 31-bit IDR is full ... */
>> + BUG_ON(ret);
>> + }
>> + spin_unlock(&hierarchy_id_lock);
>> + } while (ret);
>> + return true;
>> +}
>> +
...
>> @@ -3910,8 +3950,8 @@ static int current_css_set_cg_links_read(struct cgroup *cont,
>> name = c->dentry->d_name.name;
>> else
>> name = "?";
>> - seq_printf(seq, "Root %lu group %s\n",
>> - c->root->subsys_bits, name);
>> + seq_printf(seq, "Root %d group %s\n",
>> + c->root->hierarchy_id, name);
>> }
>
> I'm not sure but this "id" is worth to be printed ?
>
It's a debug file, so I think at least it's not bad to print the id.
next prev parent reply other threads:[~2009-07-23 8:33 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-22 19:50 [PATCH 0/4] CGroup: Support for named and empty hierarchies Paul Menage
2009-07-22 19:50 ` [PATCH 1/4] Support named cgroups hierarchies Paul Menage
2009-07-23 6:20 ` Li Zefan
2009-07-23 6:27 ` Paul Menage
2009-07-23 6:50 ` Li Zefan
2009-07-28 23:17 ` Paul Menage
2009-07-23 6:47 ` KAMEZAWA Hiroyuki
2009-07-22 19:50 ` [PATCH 2/4] Move the cgroup debug subsys into cgroup.c to access internal state Paul Menage
2009-07-23 6:21 ` Li Zefan
2009-07-23 6:51 ` KAMEZAWA Hiroyuki
2009-07-22 19:50 ` [PATCH 3/4] Add a back-pointer from struct cg_cgroup_link to struct cgroup Paul Menage
2009-07-23 6:44 ` Li Zefan
2009-07-23 14:31 ` Paul Menage
2009-07-22 19:50 ` [PATCH 4/4] Allow cgroup hierarchies to be created with no bound subsystems Paul Menage
2009-07-23 8:19 ` KAMEZAWA Hiroyuki
2009-07-23 8:32 ` Li Zefan [this message]
2009-07-24 5:21 ` Li Zefan
2009-07-23 5:13 ` [PATCH 0/4] CGroup: Support for named and empty hierarchies KAMEZAWA Hiroyuki
2009-07-23 5:37 ` Paul Menage
2009-07-23 5:45 ` KAMEZAWA Hiroyuki
-- strict thread matches above, loose matches on Subject: below --
2009-07-28 23:26 Paul Menage
2009-07-28 23:26 ` [PATCH 4/4] Allow cgroup hierarchies to be created with no bound subsystems Paul Menage
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=4A682011.5010400@cn.fujitsu.com \
--to=lizf@cn.fujitsu.com \
--cc=akpm@linux-foundation.org \
--cc=containers@lists.linux-foundation.org \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=menage@google.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox