From: Vivek Goyal on
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.

Thanks
Vivek
--
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 Thu, Jul 22, 2010 at 12:12:00PM -0700, Greg KH wrote:
> 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?

Makes sense. cgroups don't share any of the distinctive characteristics
that make pts filesystems such a natural fit in /dev: They're
not made to look like a dynamic set of character devices, there are
user-made subdirectories, there aren't any device nodes, and probably
more I'm forgetting.

In my opinion, the primary purpose of cgroups is allowing an admin/user
to organize tasks in ways they personally find useful -- so too much
"standardization" could easily be detrimental. A single standard mount
point is the first small step on that slippery slope.

If we really want to standardize then perhaps it should be based on the
names of the tools that make assumptions about how cgroups are organized.
Forgive me if my recollection is wrong, but I seem to recall systemd
imposed a certain scheme for organization of cgroups -- at least at the
top level of the subsystem(s). (That's not a bad thing. Distros/admins
that choose to use systemd are implicitly approving of systemd's
organizational scheme and any limitations it imposes). So I'd suggest
those cgroup mounts go in /var/run/systemd/cgroup or something like that.

Suppose we also have a daemon for managing applications with the freezer to
improve runtime power consumption. It might only care about the freezer
cgroup subsystem so it might choose to mount the freezer at:

/var/run/runtime_powerd/freezer

and then it would organize its cgroups according to its own schemes
(e.g. "trusted" vs "untrusted").

But if systemd and the runtime_powerd both want the freezer subsystem
then one would fail to mount it. That ensures that we don't have two
management daemons which make contradictory assumptions about cgroup
organization making a mess instead of keeping order.

Other tools that are agnostic about the organization of cgroups
shouldn't rely on a 'standard' mount point -- that way they can work
well with either of these example organizations (systemd or runtime_powerd).
They should work with an existing cgroup and its descendants -- usually
not destroying pre-existing cgroups that it did not create.

At least that's my perspective on how things can be done sanely while
giving users the flexibility to manage their own cgroups. It's also why
I think the lure of standardizing these mounts may be something to be
wary of.

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

I guess that covers all needs expressed here, and we are happy to
switch systemd over from /cgroup to /sys/fs/cgroup as soon as the
kernel carries the patch.

Thanks,
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/
From: Kay Sievers on
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.

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/
From: Greg KH on
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?

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/