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: Dhaval Giani on 26 Jul 2010 05:20 On Mon, Jul 26, 2010 at 11:12 AM, Kay Sievers <kay.sievers(a)vrfy.org> wrote: > On Mon, Jul 26, 2010 at 11:08, Dhaval Giani <dhaval.lists(a)thegianis.in> wrote: >> On Thu, Jul 22, 2010 at 8:36 PM, Greg KH <gregkh(a)suse.de> 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? >>> >> >> Not really. It is getting mounted at /cgroups/<name of resource >> controller>/ at a number of places. Keeping it in sysfs loses us a lot >> of this flexibility. Unless you are ready to keep adding a new >> mountpoint for each subsystem, it will not really work out in the long >> term. > > As mentioned earlier in this thread, systemd already mounts a tmpfs at > the cgroup mountpoint. We need only a single directory. This should > not be an issue. > Ah ok. I am catching up with email after over 3 weeks :-). Missed all this discussion. My apologies! Dhaval -- 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 26 Jul 2010 17:30 On Mon, Jul 26, 2010 at 11:13:14AM +0200, Dhaval Giani wrote: > On Mon, Jul 26, 2010 at 11:12 AM, Kay Sievers <kay.sievers(a)vrfy.org> wrote: > > On Mon, Jul 26, 2010 at 11:08, Dhaval Giani <dhaval.lists(a)thegianis.in> wrote: > >> On Thu, Jul 22, 2010 at 8:36 PM, Greg KH <gregkh(a)suse.de> 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? > >>> > >> > >> Not really. It is getting mounted at /cgroups/<name of resource > >> controller>/ at a number of places. Keeping it in sysfs loses us a lot > >> of this flexibility. Unless you are ready to keep adding a new > >> mountpoint for each subsystem, it will not really work out in the long > >> term. > > > > As mentioned earlier in this thread, systemd already mounts a tmpfs at > > the cgroup mountpoint. We need only a single directory. This should > > not be an issue. > > > > Ah ok. I am catching up with email after over 3 weeks :-). Missed all > this discussion. My apologies! Ok, again, after all of this, who is going to be applying this patch to their tree for the .36 merge window? Or should I apply it to my driver-core one? 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 26 Jul 2010 18:00 On Mon, Jul 26, 2010 at 2:28 PM, Greg KH <gregkh(a)suse.de> wrote: > > Ok, again, after all of this, who is going to be applying this patch to > their tree for the .36 merge window? There's no specific cgroups tree - cgroups patches generally go via akpm. > > Or should I apply it to my driver-core one? > That sounds like an OK option too. 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 26 Jul 2010 18:10 On Mon, Jul 26, 2010 at 02:55:18PM -0700, Paul Menage wrote: > On Mon, Jul 26, 2010 at 2:28 PM, Greg KH <gregkh(a)suse.de> wrote: > > > > Ok, again, after all of this, who is going to be applying this patch to > > their tree for the .36 merge window? > > There's no specific cgroups tree - cgroups patches generally go via akpm. > > > > > Or should I apply it to my driver-core one? > > > > That sounds like an OK option too. Wonderful, can I get some acks from the cgroups maintainers? I'll gladly take it through my tree. 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 26 Jul 2010 18:10
On Mon, Jul 26, 2010 at 3:05 PM, Greg KH <gregkh(a)suse.de> wrote: > > Wonderful, can I get some acks from the cgroups maintainers? �I'll > gladly take it through my tree. Sure. Acked-by: Paul Menage <menage(a)google.com> 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/ |