[RFC] Mount point suggestions for cgroup

[Balbir Singh-3]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[KAMEZAWA Hiroyuki]

On Wed, 4 Nov 2009 12:00:05 +0530
Balbir Singh <balbir@...> 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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Balbir Singh-3]

* KAMEZAWA Hiroyuki <kamezawa.hiroyu@...> [2009-11-04 15:40:24]:

> On Wed, 4 Nov 2009 12:00:05 +0530
> Balbir Singh <balbir@...> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Dave Hansen-5]

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Jan Safranek-2]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Balbir Singh-3]

* Jan Safranek <jsafrane@...> [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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Dhaval Giani-2]

On Wed, Nov 04, 2009 at 09:35:30PM +0530, Balbir Singh wrote:

> * Jan Safranek <jsafrane@...> [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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Serge E. Hallyn]

Quoting Dave Hansen (dave@...):
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Balbir Singh-3]

* Serge E. Hallyn <serue@...> [2009-11-04 10:11:42]:

> Quoting Dave Hansen (dave@...):
> > 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Dave Hansen-5]

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Jan Safranek-2]

On 11/04/2009 05:11 PM, Serge E. Hallyn wrote:

> Quoting Dave Hansen (dave@...):
>> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Mark Hounschell]

Dhaval Giani wrote:

> On Wed, Nov 04, 2009 at 09:35:30PM +0530, Balbir Singh wrote:
>> * Jan Safranek <jsafrane@...> [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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Alan Cox]

> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Gabor Gombas]

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
     ---------------------------------------------------------
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Daniel Lezcano-2]

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.
>  
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Paul Menage]

On Tue, Nov 3, 2009 at 10:40 PM, KAMEZAWA Hiroyuki
<kamezawa.hiroyu@...> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Matt Helsley]

On Wed, Nov 04, 2009 at 03:40:24PM +0900, KAMEZAWA Hiroyuki wrote:

> On Wed, 4 Nov 2009 12:00:05 +0530
> Balbir Singh <balbir@...> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Paul Menage]

On Wed, Nov 4, 2009 at 9:35 AM, Matt Helsley <matthltc@...> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Dhaval Giani-2]

On Wed, Nov 04, 2009 at 01:25:46PM -0800, Paul Menage wrote:

> On Wed, Nov 4, 2009 at 9:35 AM, Matt Helsley <matthltc@...> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[KOSAKI Motohiro]

> On Wed, Nov 04, 2009 at 01:25:46PM -0800, Paul Menage wrote:
> > On Wed, Nov 4, 2009 at 9:35 AM, Matt Helsley <matthltc@...> 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.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/