From: Greg KH on
On Fri, Jul 23, 2010 at 12:32:26PM +0200, Jan Safranek wrote:
> On 07/23/2010 04:07 AM, Vivek Goyal wrote:
>> On Thu, Jul 22, 2010 at 04:14:01PM -0700, Greg KH wrote:
>>> On Fri, Jul 23, 2010 at 01:08:12AM +0200, Kay Sievers wrote:
>>>> On Thu, Jul 22, 2010 at 23:18, Greg KH<gregkh(a)suse.de> wrote:
>>>>>> 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.
>>>>
>>>> Already solved. Systemd always mounts an empty tmpfs at the 'cgroup'
>>>> mountpoint, and stuff is free to create subdirs there. Systemd itself
>>>> mount 'systemd' there.
>>>
>>> Ah, that makes it easier. Paul and Vivek, any objection to this patch
>>> going in now?
>>>
>>
>> This sounds reasonable to me also.
>>
>> Jan, I know you have been working in this area and raised concenrs about
>> cgroup mount point in the past. Does it look good to you?
>
> I would prefer some place where subdirectories can be created for
> individual hierarchies without additional tmpfs there. But as I understand
> /sys, it's not an easy feature to implement it there, so no, I am not
> against /sys/fs/cgroup.

Great, thanks for letting us know.

So, who can get this patch into mainline?

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: Matt Helsley on
On Fri, Jul 23, 2010 at 01:10:43AM +0200, Kay Sievers wrote:
> On Thu, Jul 22, 2010 at 23:48, Matt Helsley <matthltc(a)us.ibm.com> wrote:
> > So I'd suggest
> > those cgroup mounts go in /var/run/systemd/cgroup or something like that.
>
> Impossible, we need it at bootup, and / is usually read-only, and /var
> might even be behind the network we need to bring up.
>
> It needs to be on tmpfs mounted on the rootsfs, or in any of the
> virtual fss we have to mount anyway, so /sys/fs seems a good place.

Ahh, excellent point. Indeed, /sys/fs seems fine then.

Cheers,
-Matt Helsley

--
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: Balbir Singh on
* Vivek Goyal <vgoyal(a)redhat.com> [2010-07-22 17:26:34]:

> On Thu, Jul 22, 2010 at 02:18:56PM -0700, Greg KH wrote:
> > 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/
>
> The only problem with /dev/cgroup seems to be that it seems little
> unintutive. To me, we have devices under /dev/ dir and cgroups are not
> devices.
>
> I think people have floated similar threads in the past on lkml with
> various opinions and everybody had their own choices but nothing was
> conclusive.
>
> Polluting / definitely sounds odd but it does not look that bad once
> we can't find any other good choices.
>

I think it breaks the filesystem hierarchy standard and I've seen
bugzilla's around it. I'd prefer /sys/fs/cgroup.

--
Three Cheers,
Balbir
--
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: Dhaval Giani on
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.

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: Kay Sievers on
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.

Kay
--
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/