Re: [RFC] Mount point suggestions for cgroup

From: Matt Helsley
Date: Wed Nov 04 2009 - 16:09:51 EST


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@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/