Hi, All,
We've been having a discussion as to what would be the right place to
mount the cgroup filesystem. Jan has been proactively looking into
this. The FHS has no recommendation since cgroup filesystem came in
much later.
The options are
1. /dev/cgroup
2. /cgroup
3. Some place under /sys
The problem with (2) is that it is quite non-standard and pollutes the
root directory. (3) requires some basic support to create a directory
for cgroup under /sys. (1) seems the most obvious choice since cpusets
were mounted under /dev/cpuset, but /dev is controlled by udev.
Given the three choices or any other suggestions, is there a general
preference as to where we can mount it? The goal is to standardize
the mount point (if possible).
BTW, the mounting is expected to be done using cgconfigparser present
in libcgroup.
--
Balbir
On Wed, 4 Nov 2009 12:00:05 +0530
Balbir Singh <[email protected]> wrote:
> Hi, All,
>
> We've been having a discussion as to what would be the right place to
> mount the cgroup filesystem. Jan has been proactively looking into
> this. The FHS has no recommendation since cgroup filesystem came in
> much later.
>
> The options are
>
> 1. /dev/cgroup
> 2. /cgroup
> 3. Some place under /sys
>
> The problem with (2) is that it is quite non-standard and pollutes the
> root directory. (3) requires some basic support to create a directory
> for cgroup under /sys. (1) seems the most obvious choice since cpusets
> were mounted under /dev/cpuset, but /dev is controlled by udev.
>
> Given the three choices or any other suggestions, is there a general
> preference as to where we can mount it? The goal is to standardize
> the mount point (if possible).
>
> BTW, the mounting is expected to be done using cgconfigparser present
> in libcgroup.
>
IMHO, even if anywhere is ok to me, the suggestion should includes the fact
- Each cgroup subsystem can be mounted independenty from other cgroup.
- some cgroup (noop) can be mounted multiple times
etc...there are some points which is different from /proc or /sys.
So, we need multiple mount points.
Then, to say my own not-seriously-considered idea, I vote for
- /cgroup/[HierarchyName]/
rather than /dev/ or /sys or /opt. This sounds straightforward.
If /sys, /sys/cgroup/[HierarchyName] will be candidate. But considering
users can use arbitarary combination of subsystem, using /sys may require
much work, I think.
Thanks,
-Kame
* KAMEZAWA Hiroyuki <[email protected]> [2009-11-04 15:40:24]:
> On Wed, 4 Nov 2009 12:00:05 +0530
> Balbir Singh <[email protected]> wrote:
>
> > Hi, All,
> >
> > We've been having a discussion as to what would be the right place to
> > mount the cgroup filesystem. Jan has been proactively looking into
> > this. The FHS has no recommendation since cgroup filesystem came in
> > much later.
> >
> > The options are
> >
> > 1. /dev/cgroup
> > 2. /cgroup
> > 3. Some place under /sys
> >
> > The problem with (2) is that it is quite non-standard and pollutes the
> > root directory. (3) requires some basic support to create a directory
> > for cgroup under /sys. (1) seems the most obvious choice since cpusets
> > were mounted under /dev/cpuset, but /dev is controlled by udev.
> >
> > Given the three choices or any other suggestions, is there a general
> > preference as to where we can mount it? The goal is to standardize
> > the mount point (if possible).
> >
> > BTW, the mounting is expected to be done using cgconfigparser present
> > in libcgroup.
> >
>
> IMHO, even if anywhere is ok to me, the suggestion should includes the fact
> - Each cgroup subsystem can be mounted independenty from other cgroup.
> - some cgroup (noop) can be mounted multiple times
> etc...there are some points which is different from /proc or /sys.
> So, we need multiple mount points.
>
> Then, to say my own not-seriously-considered idea, I vote for
> - /cgroup/[HierarchyName]/
> rather than /dev/ or /sys or /opt. This sounds straightforward.
The reason I liked /dev/cgroup was because cpusets could be
mounted at /dev/cpuset or /dev/cgroup/cpuset. My concern with /cgroup
is that a ls "/" now becomes larger in size. But I'll take your vote
for it as +1 for /cgroup.
>
> If /sys, /sys/cgroup/[HierarchyName] will be candidate. But considering
> users can use arbitarary combination of subsystem, using /sys may require
> much work, I think.
>
Yes, Agreed.
> Thanks,
> -Kame
>
--
Balbir
On Wed, 2009-11-04 at 13:46 +0530, Balbir Singh wrote:
> The reason I liked /dev/cgroup was because cpusets could be
> mounted at /dev/cpuset or /dev/cgroup/cpuset. My concern with /cgroup
> is that a ls "/" now becomes larger in size. But I'll take your vote
> for it as +1 for /cgroup.
/dev/pts is a decent precedent for doing it under /dev, although it does
deal with actual devices. cgroups do not.
-- Dave
On 11/04/2009 04:21 PM, Dave Hansen wrote:
> On Wed, 2009-11-04 at 13:46 +0530, Balbir Singh wrote:
>> The reason I liked /dev/cgroup was because cpusets could be
>> mounted at /dev/cpuset or /dev/cgroup/cpuset. My concern with /cgroup
>> is that a ls "/" now becomes larger in size. But I'll take your vote
>> for it as +1 for /cgroup.
>
> /dev/pts is a decent precedent for doing it under /dev, although it does
> deal with actual devices. cgroups do not.
There is also /dev/shm, but IMHO that's not reason to pollute /dev with
filesystems that are not devices.
Jan
* Jan Safranek <[email protected]> [2009-11-04 17:02:22]:
> On 11/04/2009 04:21 PM, Dave Hansen wrote:
> >On Wed, 2009-11-04 at 13:46 +0530, Balbir Singh wrote:
> >>The reason I liked /dev/cgroup was because cpusets could be
> >>mounted at /dev/cpuset or /dev/cgroup/cpuset. My concern with /cgroup
> >>is that a ls "/" now becomes larger in size. But I'll take your vote
> >>for it as +1 for /cgroup.
> >
> >/dev/pts is a decent precedent for doing it under /dev, although it does
> >deal with actual devices. cgroups do not.
>
> There is also /dev/shm, but IMHO that's not reason to pollute /dev
> with filesystems that are not devices.
>
Yep, but hasn't the pollution already occured with /dev/cpuset today?
sysfs would require work for changes to /sys, so do we go with Kame's
suggestion of /cgroup?
--
Balbir
On Wed, Nov 04, 2009 at 09:35:30PM +0530, Balbir Singh wrote:
> * Jan Safranek <[email protected]> [2009-11-04 17:02:22]:
>
> > On 11/04/2009 04:21 PM, Dave Hansen wrote:
> > >On Wed, 2009-11-04 at 13:46 +0530, Balbir Singh wrote:
> > >>The reason I liked /dev/cgroup was because cpusets could be
> > >>mounted at /dev/cpuset or /dev/cgroup/cpuset. My concern with /cgroup
> > >>is that a ls "/" now becomes larger in size. But I'll take your vote
> > >>for it as +1 for /cgroup.
> > >
> > >/dev/pts is a decent precedent for doing it under /dev, although it does
> > >deal with actual devices. cgroups do not.
> >
> > There is also /dev/shm, but IMHO that's not reason to pollute /dev
> > with filesystems that are not devices.
> >
>
> Yep, but hasn't the pollution already occured with /dev/cpuset today?
> sysfs would require work for changes to /sys, so do we go with Kame's
> suggestion of /cgroup?
>
I vote for /cgroup as well.
thanks,
--
regards,
Dhaval
Quoting Dave Hansen ([email protected]):
> On Wed, 2009-11-04 at 13:46 +0530, Balbir Singh wrote:
> > The reason I liked /dev/cgroup was because cpusets could be
> > mounted at /dev/cpuset or /dev/cgroup/cpuset. My concern with /cgroup
> > is that a ls "/" now becomes larger in size. But I'll take your vote
> > for it as +1 for /cgroup.
>
> /dev/pts is a decent precedent for doing it under /dev, although it does
> deal with actual devices. cgroups do not.
Hmm, on whose behalf are you making this decision?
LSB people will want to avoid using /cgroup, but I think a lot of
admins will likely prefer /cgroup (as I do). On my systems I
always use /cgroup, but would be more likely to use /mnt/cgroup
over /dev/cgroup.
lxc (at lxc.sf.net) rightfully takes the cgroupfs from wherever it
happens to be mounted. Do you really need a mountpoint decided?
If you do, then while I DETEST the extra typing, I think
/sys/kernel/cgroup makes most sense, since that's where you find
debugfs and securityfs.
-serge
* Serge E. Hallyn <[email protected]> [2009-11-04 10:11:42]:
> Quoting Dave Hansen ([email protected]):
> > On Wed, 2009-11-04 at 13:46 +0530, Balbir Singh wrote:
> > > The reason I liked /dev/cgroup was because cpusets could be
> > > mounted at /dev/cpuset or /dev/cgroup/cpuset. My concern with /cgroup
> > > is that a ls "/" now becomes larger in size. But I'll take your vote
> > > for it as +1 for /cgroup.
> >
> > /dev/pts is a decent precedent for doing it under /dev, although it does
> > deal with actual devices. cgroups do not.
>
> Hmm, on whose behalf are you making this decision?
>
> LSB people will want to avoid using /cgroup, but I think a lot of
> admins will likely prefer /cgroup (as I do). On my systems I
> always use /cgroup, but would be more likely to use /mnt/cgroup
> over /dev/cgroup.
>
> lxc (at lxc.sf.net) rightfully takes the cgroupfs from wherever it
> happens to be mounted. Do you really need a mountpoint decided?
>
> If you do, then while I DETEST the extra typing, I think
> /sys/kernel/cgroup makes most sense, since that's where you find
> debugfs and securityfs.
>
I would like to make this decision as a part of the tooling
development team for cgroups. So far we have
/cgroup +2
/sys +1
/dev +1
The concern with /sys/kernel/cgroup is that it would require creation
of sysfs directory that might not be backwards compatible way back to
2.6.24 when cgroups were first added.
--
Balbir
On Wed, 2009-11-04 at 10:11 -0600, Serge E. Hallyn wrote:
> If you do, then while I DETEST the extra typing, I think
> /sys/kernel/cgroup makes most sense, since that's where you find
> debugfs and securityfs.
Soon to be tracefs too.
-- Dave
On 11/04/2009 05:11 PM, Serge E. Hallyn wrote:
> Quoting Dave Hansen ([email protected]):
>> On Wed, 2009-11-04 at 13:46 +0530, Balbir Singh wrote:
>>> The reason I liked /dev/cgroup was because cpusets could be
>>> mounted at /dev/cpuset or /dev/cgroup/cpuset. My concern with /cgroup
>>> is that a ls "/" now becomes larger in size. But I'll take your vote
>>> for it as +1 for /cgroup.
>>
>> /dev/pts is a decent precedent for doing it under /dev, although it does
>> deal with actual devices. cgroups do not.
>
> Hmm, on whose behalf are you making this decision?
>
> LSB people will want to avoid using /cgroup,
LSB (and FHS) IMHO does not specify any place for such stuff:
/dev - for devices only, cgroups are not devices
/mnt - for admin temporary mounts and "should not affect the manner in
which any program is run"
/var - for "any unsorted variable data", cgroups are not "unsorted
variable data", it's interface to kernel
FHS does not specify either /sys and /selinux and it seems to me nobody
complains about them.
/sys/cgroup would be the best, if sysfs supported mkdir(). But it does
not :(. Our kernel guys told me it's relatively easy to create new empty
directory /sys/cgroup (or /sys/kernel/cgroup), but it must be compiled
into kernel or a module. Then I could mount some tmpfs to it, create
/sys/cgroup/cpu, /sys/cgroup/memory etc. and mount the control group
hierarchies there... but as you can see, it's really really ugly thing
to do.
Jan
Dhaval Giani wrote:
> On Wed, Nov 04, 2009 at 09:35:30PM +0530, Balbir Singh wrote:
>> * Jan Safranek <[email protected]> [2009-11-04 17:02:22]:
>>
>>> On 11/04/2009 04:21 PM, Dave Hansen wrote:
>>>> On Wed, 2009-11-04 at 13:46 +0530, Balbir Singh wrote:
>>>>> The reason I liked /dev/cgroup was because cpusets could be
>>>>> mounted at /dev/cpuset or /dev/cgroup/cpuset. My concern with /cgroup
>>>>> is that a ls "/" now becomes larger in size. But I'll take your vote
>>>>> for it as +1 for /cgroup.
>>>> /dev/pts is a decent precedent for doing it under /dev, although it does
>>>> deal with actual devices. cgroups do not.
>>> There is also /dev/shm, but IMHO that's not reason to pollute /dev
>>> with filesystems that are not devices.
>>>
>> Yep, but hasn't the pollution already occured with /dev/cpuset today?
>> sysfs would require work for changes to /sys, so do we go with Kame's
>> suggestion of /cgroup?
>>
>
> I vote for /cgroup as well.
>
> thanks,
If this is really a voting matter, I would vote for /sys even if it does require someone to do some work, and also
the /dev/cpuset stuff to also move to /sys. IE /sys/cgroup/cpuset etc.. Leave / and /dev alone.
thanks
mark
> If you do, then while I DETEST the extra typing, I think
> /sys/kernel/cgroup makes most sense, since that's where you find
> debugfs and securityfs.
And for everyone else
man ln
We have the technology ...
Alan
On Wed, Nov 04, 2009 at 09:35:30PM +0530, Balbir Singh wrote:
> Yep, but hasn't the pollution already occured with /dev/cpuset today?
> sysfs would require work for changes to /sys, so do we go with Kame's
> suggestion of /cgroup?
debugfs is already under /sys.
If /dev is not popular, then how about dedicating a location (say
/kernel) as a base for mounting virtual file systems? So cgroups can get
/kernel/cgroup. hugetlbfs is often mounted on /dev/hugepages but that
does not seem to be standardized as well, so it could be the second
citizen under /kernel. configfs could be moved there too. Having a
different rule for every new virtual fs does not seem to be a good
idea...
Gabor
--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------
Balbir Singh wrote:
> Hi, All,
>
> We've been having a discussion as to what would be the right place to
> mount the cgroup filesystem. Jan has been proactively looking into
> this. The FHS has no recommendation since cgroup filesystem came in
> much later.
>
> The options are
>
> 1. /dev/cgroup
> 2. /cgroup
> 3. Some place under /sys
>
> The problem with (2) is that it is quite non-standard and pollutes the
> root directory. (3) requires some basic support to create a directory
> for cgroup under /sys. (1) seems the most obvious choice since cpusets
> were mounted under /dev/cpuset, but /dev is controlled by udev.
>
> Given the three choices or any other suggestions, is there a general
> preference as to where we can mount it? The goal is to standardize
> the mount point (if possible).
>
Why the mount point has to be standardized ?
> BTW, the mounting is expected to be done using cgconfigparser present
> in libcgroup.
>
On Tue, Nov 3, 2009 at 10:40 PM, KAMEZAWA Hiroyuki
<[email protected]> wrote:
>
> Then, to say my own not-seriously-considered idea, I vote for
> ?- /cgroup/[HierarchyName]/
> rather than /dev/ or /sys or /opt. This sounds straightforward.
We're using /dev/cgroup (for single mounts) or
/dev/cgroup/$hierarchy_name (for multiple-mount configurations) but
that's mostly just due to the historical accident of /dev/cpuset. So
/cgroup/$hierarchy_name sounds plausible, or /kernel/cgroup/... as
suggested in another email.
Paul
On Wed, Nov 04, 2009 at 03:40:24PM +0900, KAMEZAWA Hiroyuki wrote:
> On Wed, 4 Nov 2009 12:00:05 +0530
> Balbir Singh <[email protected]> wrote:
>
> > Hi, All,
> >
> > We've been having a discussion as to what would be the right place to
> > mount the cgroup filesystem. Jan has been proactively looking into
> > this. The FHS has no recommendation since cgroup filesystem came in
> > much later.
> >
> > The options are
> >
> > 1. /dev/cgroup
> > 2. /cgroup
> > 3. Some place under /sys
> >
> > The problem with (2) is that it is quite non-standard and pollutes the
> > root directory. (3) requires some basic support to create a directory
> > for cgroup under /sys. (1) seems the most obvious choice since cpusets
> > were mounted under /dev/cpuset, but /dev is controlled by udev.
> >
> > Given the three choices or any other suggestions, is there a general
> > preference as to where we can mount it? The goal is to standardize
> > the mount point (if possible).
> >
> > BTW, the mounting is expected to be done using cgconfigparser present
> > in libcgroup.
> >
>
> IMHO, even if anywhere is ok to me, the suggestion should includes the fact
> - Each cgroup subsystem can be mounted independenty from other cgroup.
> - some cgroup (noop) can be mounted multiple times
> etc...there are some points which is different from /proc or /sys.
> So, we need multiple mount points.
>
> Then, to say my own not-seriously-considered idea, I vote for
> - /cgroup/[HierarchyName]/
> rather than /dev/ or /sys or /opt. This sounds straightforward.
>
> If /sys, /sys/cgroup/[HierarchyName] will be candidate. But considering
> users can use arbitarary combination of subsystem, using /sys may require
> much work, I think.
I agree.
If anything, "standardizing" the mount point(s) will likely provide a false
sense of uniformity and we'll get some bad userspace scripts/tools that
break when "nonstandard" usage appears. Leaving the mount point undefined
forces anyone writing scripts or tools to consider whether they want to be
portable and, if so, the proper way to find the cgroup hierarchies they need
to manipulate.
Cheers,
-Matt Helsley
On Wed, Nov 4, 2009 at 9:35 AM, Matt Helsley <[email protected]> wrote:
>
> If anything, "standardizing" the mount point(s) will likely provide a false
> sense of uniformity and we'll get some bad userspace scripts/tools that
> break when "nonstandard" usage appears. Leaving the mount point undefined
> forces anyone writing scripts or tools to consider whether they want to be
> portable and, if so, the proper way to find the cgroup hierarchies they need
> to manipulate.
Scanning /proc/mounts to find the relevant mount locations is pretty
simple, for code that's just wanting to use existing cgroup mounts.
But for the code that sets up mounts in the first place, its probably
helpful to have recommendations of suitable locations.
Paul
On Wed, Nov 04, 2009 at 01:25:46PM -0800, Paul Menage wrote:
> On Wed, Nov 4, 2009 at 9:35 AM, Matt Helsley <[email protected]> wrote:
> >
> > If anything, "standardizing" the mount point(s) will likely provide a false
> > sense of uniformity and we'll get some bad userspace scripts/tools that
> > break when "nonstandard" usage appears. Leaving the mount point undefined
> > forces anyone writing scripts or tools to consider whether they want to be
> > portable and, if so, the proper way to find the cgroup hierarchies they need
> > to manipulate.
>
> Scanning /proc/mounts to find the relevant mount locations is pretty
> simple, for code that's just wanting to use existing cgroup mounts.
> But for the code that sets up mounts in the first place, its probably
> helpful to have recommendations of suitable locations.
>
libcgroup uses a configuration file specified by the user to do this.
thanks,
--
regards,
Dhaval
> On Wed, Nov 04, 2009 at 01:25:46PM -0800, Paul Menage wrote:
> > On Wed, Nov 4, 2009 at 9:35 AM, Matt Helsley <[email protected]> wrote:
> > >
> > > If anything, "standardizing" the mount point(s) will likely provide a false
> > > sense of uniformity and we'll get some bad userspace scripts/tools that
> > > break when "nonstandard" usage appears. Leaving the mount point undefined
> > > forces anyone writing scripts or tools to consider whether they want to be
> > > portable and, if so, the proper way to find the cgroup hierarchies they need
> > > to manipulate.
> >
> > Scanning /proc/mounts to find the relevant mount locations is pretty
> > simple, for code that's just wanting to use existing cgroup mounts.
> > But for the code that sets up mounts in the first place, its probably
> > helpful to have recommendations of suitable locations.
>
> libcgroup uses a configuration file specified by the user to do this.
You are right.
But fixed mount point help to make quick cute script for sys-admin.
On Wed, Nov 04, 2009 at 01:25:46PM -0800, Paul Menage wrote:
> On Wed, Nov 4, 2009 at 9:35 AM, Matt Helsley <[email protected]> wrote:
> >
> > If anything, "standardizing" the mount point(s) will likely provide a false
> > sense of uniformity and we'll get some bad userspace scripts/tools that
> > break when "nonstandard" usage appears. Leaving the mount point undefined
> > forces anyone writing scripts or tools to consider whether they want to be
> > portable and, if so, the proper way to find the cgroup hierarchies they need
> > to manipulate.
>
> Scanning /proc/mounts to find the relevant mount locations is pretty
> simple, for code that's just wanting to use existing cgroup mounts.
> But for the code that sets up mounts in the first place, its probably
> helpful to have recommendations of suitable locations.
If the tool set up the mounts in the first place then there's nothing
gained, as far as the code is concerned, by standardizing the location.
It could just as easily make a temporary directory and put it there.
If it's specified in an /etc file by the user then standardization
gets us nothing but inflexibility. The user knows where it is (they set it)
and the code knows where it is (via /proc OR /etc).
Recommending default locations seems helpful only so that users can inspect
what the code does. Blessing one location as the "standard, one, true location"
for code to use -- via FHS/LSB/whatnot -- seems like asking for trouble.
Cheers,
-Matt
On Wed, Nov 04, 2009 at 05:24:46PM +0100, Jan Safranek wrote:
> LSB (and FHS) IMHO does not specify any place for such stuff:
>
> /dev - for devices only, cgroups are not devices
The FHS says the following for /dev on Linux:
/dev : Devices and special files
IMHO cgroups are covered by "special files".
Gabor
--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------
On 11/04/2009 05:44 PM, Daniel Lezcano wrote:
> Balbir Singh wrote:
>> Hi, All,
>>
>> We've been having a discussion as to what would be the right place to
>> mount the cgroup filesystem. Jan has been proactively looking into
>> this. The FHS has no recommendation since cgroup filesystem came in
>> much later.
>>
>> The options are
>>
>> 1. /dev/cgroup
>> 2. /cgroup
>> 3. Some place under /sys
>>
>> The problem with (2) is that it is quite non-standard and pollutes the
>> root directory. (3) requires some basic support to create a directory
>> for cgroup under /sys. (1) seems the most obvious choice since cpusets
>> were mounted under /dev/cpuset, but /dev is controlled by udev.
>>
>> Given the three choices or any other suggestions, is there a general
>> preference as to where we can mount it? The goal is to standardize
>> the mount point (if possible).
> Why the mount point has to be standardized ?
>
The mount point does not need to be set into stone so everybody *must*
use it. I, as Fedora packager, just need some default place where to
mount it, so applications which need to create/manage groups work
without any (potentially dumb) user assistance. Of course, advanced
admin can change the settings and move the groups anywhere, applications
still need to parse /proc/mounts or use appropriate library like libcgroup.
Jan
* Jan Safranek <[email protected]> [2009-11-05 13:07:28]:
> On 11/04/2009 05:44 PM, Daniel Lezcano wrote:
> >Balbir Singh wrote:
> >>Hi, All,
> >>
> >>We've been having a discussion as to what would be the right place to
> >>mount the cgroup filesystem. Jan has been proactively looking into
> >>this. The FHS has no recommendation since cgroup filesystem came in
> >>much later.
> >>
> >>The options are
> >>
> >>1. /dev/cgroup
> >>2. /cgroup
> >>3. Some place under /sys
> >>
> >>The problem with (2) is that it is quite non-standard and pollutes the
> >>root directory. (3) requires some basic support to create a directory
> >>for cgroup under /sys. (1) seems the most obvious choice since cpusets
> >>were mounted under /dev/cpuset, but /dev is controlled by udev.
> >>
> >>Given the three choices or any other suggestions, is there a general
> >>preference as to where we can mount it? The goal is to standardize
> >>the mount point (if possible).
> >Why the mount point has to be standardized ?
> >
>
> The mount point does not need to be set into stone so everybody
> *must* use it. I, as Fedora packager, just need some default place
> where to mount it, so applications which need to create/manage
> groups work without any (potentially dumb) user assistance.
I see no consensus, there are different approaches people like. I
wonder if we can create an empty directory under /sys/kernel/cgroup,
if so we would have supported the /sys approach. I'll send out a patch
to do the same.
Of
> course, advanced admin can change the settings and move the groups
> anywhere, applications still need to parse /proc/mounts or use
> appropriate library like libcgroup.
Agreed.
--
Balbir
2009/11/4 KAMEZAWA Hiroyuki <[email protected]>:
> Then, to say my own not-seriously-considered idea, I vote for
> ?- /cgroup/[HierarchyName]/
> rather than /dev/ or /sys or /opt. This sounds straightforward.
I second this. IMHO it is more important to enforce that the mounts
below the topdir are named after the subsystem and only mounted
once for each subsystem, avoiding the multiple-subsystem mounts,
which are a funny way of doing things but in my experience useless.
I have used this hierarchy under /cgroup with libcgroup and
CGFreak in the preliminary Fedora packages and it works like a
charm.
Linus Walleij
On Wed 2009-11-04 12:00:05, Balbir Singh wrote:
> Hi, All,
>
> We've been having a discussion as to what would be the right place to
> mount the cgroup filesystem. Jan has been proactively looking into
> this. The FHS has no recommendation since cgroup filesystem came in
> much later.
>
> The options are
>
> 1. /dev/cgroup
> 2. /cgroup
> 3. Some place under /sys
Underr /sys, please. Actually I wonder that it may even belong /proc
... It *is* process related, right?
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
* Pavel Machek <[email protected]> [2009-11-08 18:05:12]:
> On Wed 2009-11-04 12:00:05, Balbir Singh wrote:
> > Hi, All,
> >
> > We've been having a discussion as to what would be the right place to
> > mount the cgroup filesystem. Jan has been proactively looking into
> > this. The FHS has no recommendation since cgroup filesystem came in
> > much later.
> >
> > The options are
> >
> > 1. /dev/cgroup
> > 2. /cgroup
> > 3. Some place under /sys
>
> Underr /sys, please. Actually I wonder that it may even belong /proc
> ... It *is* process related, right?
>
We already have /proc/cgroups for showing currently supported
subsystems and /proc/pid/cgroups to show which subsystems/tasks
--
Balbir