mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Matt Helsley <matthltc@us.ibm.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: balbir@linux.vnet.ibm.com,
	Dhaval Giani <dhaval@linux.vnet.ibm.com>,
	containers@lists.linux-foundation.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jan@smtp1.linux-foundation.org,
	Bharata B Rao <bharata.rao@in.ibm.com>,
	libcg-devel <libcg-devel@lists.sourceforge.net>,
	"menage@google.com" <menage@google.com>,
	Safranek <jsafrane@redhat.com>
Subject: Re: [RFC] Mount point suggestions for cgroup
Date: Wed, 4 Nov 2009 09:35:17 -0800	[thread overview]
Message-ID: <20091104173517.GA3668@count0.beaverton.ibm.com> (raw)
In-Reply-To: <20091104154024.0b8f6123.kamezawa.hiroyu@jp.fujitsu.com>

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@linux.vnet.ibm.com> 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

  parent reply	other threads:[~2009-11-04 21:09 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-04  6:30 Balbir Singh
2009-11-04  6:40 ` KAMEZAWA Hiroyuki
2009-11-04  8:16   ` Balbir Singh
2009-11-04 15:21     ` Dave Hansen
2009-11-04 16:02       ` Jan Safranek
2009-11-04 16:05         ` Balbir Singh
2009-11-04 16:09           ` Dhaval Giani
2009-11-04 16:27             ` Mark Hounschell
2009-11-04 16:38           ` Gabor Gombas
2009-11-04 16:11       ` Serge E. Hallyn
2009-11-04 16:18         ` Balbir Singh
2009-11-04 16:20         ` Dave Hansen
2009-11-04 16:24         ` Jan Safranek
2009-11-05  8:26           ` Gabor Gombas
2009-11-04 16:35         ` Alan Cox
2009-11-04 17:19   ` Paul Menage
2009-11-04 17:35   ` Matt Helsley [this message]
2009-11-04 21:25     ` Paul Menage
2009-11-04 21:40       ` Dhaval Giani
2009-11-04 23:34         ` KOSAKI Motohiro
2009-11-04 23:37       ` Matt Helsley
2009-11-07 15:23   ` Linus Walleij
2009-11-04 16:44 ` Daniel Lezcano
2009-11-05 12:07   ` Jan Safranek
2009-11-06  7:32     ` Balbir Singh
2009-11-08 17:05 ` Pavel Machek
2009-11-09  5:05   ` 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=20091104173517.GA3668@count0.beaverton.ibm.com \
    --to=matthltc@us.ibm.com \
    --cc=Jan@smtp1.linux-foundation.org \
    --cc=balbir@linux.vnet.ibm.com \
    --cc=bharata.rao@in.ibm.com \
    --cc=containers@lists.linux-foundation.org \
    --cc=dhaval@linux.vnet.ibm.com \
    --cc=jsafrane@redhat.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=libcg-devel@lists.sourceforge.net \
    --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

all inboxes | Powered by JetHome®