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 15:20 On Thu, Jul 22, 2010 at 12:07:43PM -0700, Paul Menage wrote: > 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?). Yeah, /dev/pts and /dev/shm are long-time users of the /dev filesystem. I don't know if we want to encourage that as a mount point, do you? What are the different names you are giving to your mount points now for cgroupfs so I can get an idea of how it is used currently? 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:20 On Thu, Jul 22, 2010 at 12:12 PM, Greg KH <gregkh(a)suse.de> wrote: > I don't know if we want to encourage that as a mount point, do you? No. > > What are the different names you are giving to your mount points now for > cgroupfs so I can get an idea of how it is used currently? > We don't particularly care about the names of the individual sub-mounts, since it's all programatically controlled. We just specify which subsystems we want grouped together (and a catch-all remainder hierarchy) and the system picks the name of one of the subsystems in the hierarchy to act as a unique mountpoint name (since each subsystem can only be in one hierarchy). So e.g. /dev/cgroup/cpuset, or /dev/cgroup/io 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: Vivek Goyal on 22 Jul 2010 15:40 On Thu, Jul 22, 2010 at 11:36:15AM -0700, Greg KH wrote: > 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? > Greg, [CCing few more folks who might be interested in this dicussion ] We do want to retain facility to mount different controllers at different mount points. We were discussing the other day that in libvirt we might want to mount block IO controller and network controller separately as by default we will not put a new virtual machine in a cgroup of its own because of the penatly involved. For other controllers like cpu, memory etc, libvirt automatically puts each new virtual machine in a cgroup of own. So this is one use case where we might want to mount different controllers at different mount points. For my testing I now always use /cgroup/ and create directories under it /cgroup/blkio /cgroup/cpu etc and mount controllers on respective directories. Thanks Vivek > 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/ -- 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 17:30 On Thu, Jul 22, 2010 at 12:18:13PM -0700, Paul Menage wrote: > On Thu, Jul 22, 2010 at 12:12 PM, Greg KH <gregkh(a)suse.de> wrote: > > I don't know if we want to encourage that as a mount point, do you? > > No. Heh. > > What are the different names you are giving to your mount points now for > > cgroupfs so I can get an idea of how it is used currently? > > > > We don't particularly care about the names of the individual > sub-mounts, since it's all programatically controlled. We just specify > which subsystems we want grouped together (and a catch-all remainder > hierarchy) and the system picks the name of one of the subsystems in > the hierarchy to act as a unique mountpoint name (since each subsystem > can only be in one hierarchy). So e.g. /dev/cgroup/cpuset, or > /dev/cgroup/io Thanks for the info. But in the end, I really don't want to see a /cgroup/ mountpoint added to people's systems if at all possible. Any suggestions from your side? 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: Greg KH on 22 Jul 2010 17:30
On Thu, Jul 22, 2010 at 03:37:41PM -0400, Vivek Goyal wrote: > On Thu, Jul 22, 2010 at 11:36:15AM -0700, Greg KH wrote: > > 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? > > > > Greg, > > [CCing few more folks who might be interested in this dicussion ] > > We do want to retain facility to mount different controllers at different > mount points. We were discussing the other day that in libvirt we might > want to mount block IO controller and network controller separately as > by default we will not put a new virtual machine in a cgroup of its own > because of the penatly involved. That's fine, I'm not changing that ability at all. We just need a "default" mount point for "normal" users. > For other controllers like cpu, memory etc, libvirt automatically puts > each new virtual machine in a cgroup of own. So this is one use case > where we might want to mount different controllers at different mount > points. > > For my testing I now always use /cgroup/ and create directories under it > /cgroup/blkio /cgroup/cpu etc and mount controllers on respective > directories. Lennart and Kay, is this what systemd is doing? I really don't think we should be adding a root /cgroup/ mount point to the system for something like this. Maybe /dev/cgroup/ is better to use, as that way users can create sub-mount points easier. They can't do that in /sys/fs/cgroup/ 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/ |