cgroupfs: create /sys/fs/cgroup to mount cgroupfs on
in [Kernel]
|
Prev: [PATCH 11/31] memblock: Remove memblock_type.size and add memblock.memory_size instead
Next: [PATCH 12/31] memblock: Move memblock arrays to static storage in memblock.c and make their size a variable
From: Greg KH on 22 Jul 2010 14:40 On Thu, Jul 22, 2010 at 11:31:07AM -0700, Paul Menage wrote: > On Thu, Jul 22, 2010 at 11:26 AM, Greg KH <gregkh(a)suse.de> wrote: > > We really shouldn't be asking userspace to create new root filesystems. > > So follow along with all of the other in-kernel filesystems, and provide > > a mount point in sysfs. > > > > For cgroupfs, this should be in /sys/fs/cgroup/ �This change provides > > that mount point when the cgroup filesystem is registered in the kernel. > > But cgroups will typically have multiple mounts, with different > resource controllers/options on each mount. That doesn't really fit in > with this scheme. Really? I see systems mounting it at /cgroups/ in the filesystem today. Where are you expecting it to be mounted at? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Paul Menage on 22 Jul 2010 14:40 On Thu, Jul 22, 2010 at 11:26 AM, Greg KH <gregkh(a)suse.de> wrote: > We really shouldn't be asking userspace to create new root filesystems. > So follow along with all of the other in-kernel filesystems, and provide > a mount point in sysfs. > > For cgroupfs, this should be in /sys/fs/cgroup/ �This change provides > that mount point when the cgroup filesystem is registered in the kernel. But cgroups will typically have multiple mounts, with different resource controllers/options on each mount. That doesn't really fit in with this scheme. Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Paul Menage on 22 Jul 2010 14:50 On Thu, Jul 22, 2010 at 11:36 AM, Greg KH <gregkh(a)suse.de> wrote: > > Really? �I see systems mounting it at /cgroups/ in the filesystem today. Sure, it *can* be mounted as a single instance, but you then lose flexibility. E.g. at Google we want to have a different hierarchy for the CPU subsystem (with the tree grouped according to latency-sensitive versus batch, etc) and memory (grouped according to what jobs are sharing memory with each other). > Where are you expecting it to be mounted at? I have no particular expectation. (At Google we're actually using /dev/cgroup/* but that's just for historical reasons, from /dev/cpuset). Under /sys/fs/cgroup sounds reasonable, but you'd want people to have the ability to manually create subdirs in there for separate mount points. Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Greg KH on 22 Jul 2010 15:00 On Thu, Jul 22, 2010 at 11:44:50AM -0700, Paul Menage wrote: > On Thu, Jul 22, 2010 at 11:36 AM, Greg KH <gregkh(a)suse.de> wrote: > > > > Really? �I see systems mounting it at /cgroups/ in the filesystem today. > > Sure, it *can* be mounted as a single instance, but you then lose > flexibility. E.g. at Google we want to have a different hierarchy for > the CPU subsystem (with the tree grouped according to > latency-sensitive versus batch, etc) and memory (grouped according to > what jobs are sharing memory with each other). > > > Where are you expecting it to be mounted at? > > I have no particular expectation. (At Google we're actually using > /dev/cgroup/* but that's just for historical reasons, from > /dev/cpuset). Under /sys/fs/cgroup sounds reasonable, but you'd want > people to have the ability to manually create subdirs in there for > separate mount points. Ok, that's great, but it's not where the distros are starting to mount it at. As I learned with debugfs, you need to pick a location for people to mount it at, otherwise it ends up all over the place. If you are using /dev/cgroup/ that's nice, but I don't think that people are expecting a whole filesystem under a /dev/ subdirectory. I didn't realize that cgroupfs had so many different options that would enable it to handle multiple mounts in this way. Hm, Lennart, Kay, any ideas as to where to put it in a "standard" way? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Paul Menage on 22 Jul 2010 15:10
On Thu, Jul 22, 2010 at 11:53 AM, Greg KH <gregkh(a)suse.de> wrote: > > If you are using /dev/cgroup/ that's nice, but I don't think that people > are expecting a whole filesystem under a /dev/ subdirectory. Sure - as I said that's just for historical reasons from when we migrated from cpusets which were traditionally mounted at /dev/cpuset, so it involved less change. There's no particular reason to mount it there (although having said that, what about /dev/pts and /dev/shm?). Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |