cgroupfs: create /sys/fs/cgroup to mount cgroupfs on
PATCH 1/1 cgroupfs: create /sys/fs/cgroup to mount cgroupfs on
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.
kernel/cgroup.c +12 -1
@@ -1623,6 +1623,8 @@ static struct file_system_type cgroup_fs_type = { .kill_sb = cgroup_kill_sb, }; +static struct kobject *cgroup_kobj; +static inline struct cgroup *__d_cgrp (struct dentry *dentry) {return dentry->d_fsdata;
@@ -3871,9 +3873,18 @@ int __init cgroup_init(void) hhead =css_set_hash (init_css_set.subsys);hlist_add_head (&init_css_set.hlist, hhead);BUG_ON (!init_root_id (&rootnode)); + + cgroup_kobj =kobject_create_and_add ("cgroup" , fs_kobj); +if (!cgroup_kobj) { + err = -ENOMEM ; + goto out; + } + err =register_filesystem (&cgroup_fs_type); -if (err <0 ) +if (err <0 ) { +kobject_put (cgroup_kobj); goto out; + }proc_create ("cgroups" ,0 ,NULL , &proc_cgroupstats_operations);
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 6 lines · Greg KH
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
Quoted 6 lines · Greg KH
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
A message that is not in the archive (sent off-list or not yet received): AANLkTinRGBksuWAZhdmvr39FNACU18+kc5ut49VUf=mp-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Quoted 11 lines · Paul Menage
Quoted 6 lines · Greg KH
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
Quoted 11 lines · Paul Menage
Quoted 6 lines · Greg KH
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
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 2 lines · Greg KH
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).
Quoted 1 line
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
Quoted 9 lines · Greg KH
Quoted 8 lines · Paul Menage
Quoted 6 lines · Greg KH
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.
Quoted 7 lines
Quoted 3 lines
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
Quoted 8 lines
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Quoted 2 lines · Greg KH
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).
Quoted 1 line
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
A message that is not in the archive (sent off-list or not yet received): AANLkTimbcuzH6_bBhYX0U6vqftYgRwE0ZTmcbaRNzXef-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Quoted 10 lines · Paul Menage
Quoted 2 lines · Greg KH
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).
Quoted 7 lines
Quoted 1 line
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/cgroupsounds 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
Quoted 10 lines · Paul Menage
Quoted 2 lines · Greg KH
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).
Quoted 7 lines
Quoted 1 line
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/cgroupsounds 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
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 3 lines · Greg KH
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
Quoted 3 lines · Greg KH
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
A message that is not in the archive (sent off-list or not yet received): AANLkTik07hZot_x0p7xJuY8s4f8pGRd2Mn1+jYfHH2iq-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Quoted 9 lines · Paul Menage
Quoted 3 lines · Greg KH
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/ptsand/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
Quoted 9 lines · Paul Menage
Quoted 3 lines · Greg KH
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/ptsand/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
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 1 line · Greg KH
I don't know if we want to encourage that as a mount point, do you?
No.
Quoted 4 lines
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
Quoted 6 lines · Greg KH
Quoted 5 lines · Paul Menage
Quoted 3 lines · Greg KH
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.
Quoted 7 lines
Quoted 4 lines
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/ptsand/dev/shm?).Yeah,
/dev/ptsand/dev/shmare 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
Quoted 1 line · Greg KH
I don't know if we want to encourage that as a mount point, do you?
No.
Quoted 4 lines
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
A message that is not in the archive (sent off-list or not yet received): AANLkTi=8TTeGG3OTbP4zzNAe_rDaNNL8D0Yxp7DixohK-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Quoted 4 lines · Paul Menage
Quoted 1 line · Greg KH
I don't know if we want to encourage that as a mount point, do you?
No.
Heh.
Quoted 11 lines
Quoted 3 lines
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
Quoted 4 lines · Paul Menage
Quoted 1 line · Greg KH
I don't know if we want to encourage that as a mount point, do you?
No.
Heh.
Quoted 11 lines
Quoted 3 lines
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
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 3 lines · Greg KH
Any suggestions from your side?
I'd probably go with Matt's suggestion of /var/run.
Paul
Quoted 3 lines · Greg KH
Any suggestions from your side?
I'd probably go with Matt's suggestion of /var/run.
Paul
A message that is not in the archive (sent off-list or not yet received): AANLkTimwUC_ToxADRR9n5_KLFVHgL=ymMngXAyt+OboJ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Quoted 6 lines · Paul Menage
Quoted 3 lines · Greg KH
Any suggestions from your side?
I'd probably go with Matt's suggestion of
/var/run.
See Kay's answer for why this will not work.
sorry,
greg k-h
Quoted 6 lines · Paul Menage
Quoted 3 lines · Greg KH
Any suggestions from your side?
I'd probably go with Matt's suggestion of
/var/run.
See Kay's answer for why this will not work.
sorry,
greg k-h
Quoted 6 lines · Greg KH
Quoted 5 lines · Paul Menage
Quoted 3 lines · Greg KH
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.
Quoted 7 lines
Quoted 4 lines
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/ptsand/dev/shm?).Yeah,
/dev/ptsand/dev/shmare 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
A message that is not in the archive (sent off-list or not yet received): 20100722214821.GB14303-52DBMbEzqgQ/wnmkkaCWp/[email protected]
Quoted 2 lines · Matt Helsley
So I'd suggest
those cgroup mounts go in/var/run/systemd/cgroupor 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
Quoted 2 lines · Matt Helsley
So I'd suggest
those cgroup mounts go in/var/run/systemd/cgroupor 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
A message that is not in the archive (sent off-list or not yet received): AANLkTikluqTBi3XsU-OT_IJuBdkURkHpM3ut-8ratnzr-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Quoted 9 lines · Kay Sievers
Quoted 2 lines · Matt Helsley
So I'd suggest
those cgroup mounts go in/var/run/systemd/cgroupor 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/fsseems a good place.
Ahh, excellent point. Indeed, /sys/fs seems fine then.
Cheers,
-Matt Helsley
Quoted 9 lines · Kay Sievers
Quoted 2 lines · Matt Helsley
So I'd suggest
those cgroup mounts go in/var/run/systemd/cgroupor 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/fsseems a good place.
Ahh, excellent point. Indeed, /sys/fs seems fine then.
Cheers,
-Matt Helsley
Quoted 9 lines · Greg KH
Quoted 8 lines · Paul Menage
Quoted 6 lines · Greg KH
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.
Quoted 7 lines
Quoted 3 lines
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
Quoted 8 lines
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 20 lines · Vivek Goyal
Quoted 9 lines · Greg KH
Quoted 8 lines · Paul Menage
Quoted 6 lines · Greg KH
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.Quoted 7 lines
Quoted 3 lines
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,
Quoted 7 lines
[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.
Quoted 8 lines
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
Quoted 20 lines · Vivek Goyal
Quoted 9 lines · Greg KH
Quoted 8 lines · Paul Menage
Quoted 6 lines · Greg KH
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.Quoted 7 lines
Quoted 3 lines
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,
Quoted 7 lines
[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.
Quoted 8 lines
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
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 41 lines · Greg KH
Quoted 20 lines · Vivek Goyal
Quoted 9 lines · Greg KH
Quoted 8 lines · Paul Menage
Quoted 6 lines · Greg KH
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.Quoted 7 lines
Quoted 3 lines
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,
Quoted 7 lines
[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.
Quoted 8 lines
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.
Quoted 6 lines
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
Quoted 7 lines · Greg KH
Quoted 3 lines
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
_______________________________________________
Containers mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/containers
Quoted 41 lines · Greg KH
Quoted 20 lines · Vivek Goyal
Quoted 9 lines · Greg KH
Quoted 8 lines · Paul Menage
Quoted 6 lines · Greg KH
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.Quoted 7 lines
Quoted 3 lines
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,
Quoted 7 lines
[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.
Quoted 8 lines
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.
Quoted 6 lines
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
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 53 lines · Vivek Goyal
Quoted 41 lines · Greg KH
Quoted 20 lines · Vivek Goyal
Quoted 9 lines · Greg KH
Quoted 8 lines · Paul Menage
Quoted 6 lines · Greg KH
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.Quoted 7 lines
Quoted 3 lines
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,
Quoted 7 lines
[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.
Quoted 8 lines
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.
Quoted 6 lines
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/cgroupseems to be that it seems little unintutive. To me, we have devices under/dev/dir and cgroups are not devices.
Quoted 6 lines
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 /sys/fs/cgroup/ is a better choice than polluting /
thanks,
greg k-h
Quoted 53 lines · Vivek Goyal
Quoted 41 lines · Greg KH
Quoted 20 lines · Vivek Goyal
Quoted 9 lines · Greg KH
Quoted 8 lines · Paul Menage
Quoted 6 lines · Greg KH
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.Quoted 7 lines
Quoted 3 lines
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,
Quoted 7 lines
[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.
Quoted 8 lines
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.
Quoted 6 lines
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/cgroupseems to be that it seems little unintutive. To me, we have devices under/dev/dir and cgroups are not devices.
Quoted 7 lines
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.
Signature · 2 lines
Three Cheers, Balbir
Quoted 53 lines · Vivek Goyal
Quoted 41 lines · Greg KH
Quoted 20 lines · Vivek Goyal
Quoted 9 lines · Greg KH
Quoted 8 lines · Paul Menage
Quoted 6 lines · Greg KH
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.Quoted 7 lines
Quoted 3 lines
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,
Quoted 7 lines
[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.
Quoted 8 lines
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.
Quoted 6 lines
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/cgroupseems to be that it seems little unintutive. To me, we have devices under/dev/dir and cgroups are not devices.
Quoted 6 lines
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 /sys/fs/cgroup/ is a better choice than polluting /
thanks,
greg k-h
Quoted 53 lines · Vivek Goyal
Quoted 41 lines · Greg KH
Quoted 20 lines · Vivek Goyal
Quoted 9 lines · Greg KH
Quoted 8 lines · Paul Menage
Quoted 6 lines · Greg KH
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.Quoted 7 lines
Quoted 3 lines
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,
Quoted 7 lines
[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.
Quoted 8 lines
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.
Quoted 6 lines
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/cgroupseems to be that it seems little unintutive. To me, we have devices under/dev/dir and cgroups are not devices.
Quoted 7 lines
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.
Signature · 2 lines
Three Cheers, Balbir
Quoted 7 lines · Greg KH
Quoted 3 lines
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
A message that is not in the archive (sent off-list or not yet received): AANLkTinFQtwrCC82T9KlKskDV8fn-zYgimyH2wguHkqY-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Quoted 5 lines · Kay Sievers
Quoted 4 lines · Greg KH
Quoted 3 lines
For my testing I now always use /cgroup/ and create directories under it /cgroup/blkio /cgroup/cpu etc and mount controllers on respective directories.
Quoted 7 lines
Quoted 3 lines
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
Quoted 5 lines · Kay Sievers
Quoted 4 lines · Greg KH
Quoted 3 lines
For my testing I now always use /cgroup/ and create directories under it /cgroup/blkio /cgroup/cpu etc and mount controllers on respective directories.
Quoted 7 lines
Quoted 3 lines
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
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 4 lines · Greg KH
Ah, that makes it easier. Paul and Vivek, any objection to this patch going in now?
Sounds reasonable.
Paul
Quoted 10 lines · Greg KH
Quoted 9 lines · Kay Sievers
Quoted 7 lines · Greg KH
Quoted 3 lines
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.
Quoted 6 lines
Quoted 3 lines
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?
Just to get an idea, here is the current output on a systemd system:
/dev/sda3 /home/kay/work ext3 rw,noatime,errors=continue,user_xattr,acl,barrier=0,data=writeback 0 0 devtmpfs /dev devtmpfs rw,relatime,size=1965252k,nr_inodes=491313,mode=755 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
tmpfs /dev/shm tmpfs rw,relatime 0 0
devpts /dev/pts devpts rw,relatime,mode=600 0 0
tmpfs /cgroup tmpfs rw,nosuid,nodev,noexec,relatime,mode=755 0 0
cgroup /cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd 0 0 systemd-1 /dev/mqueue autofs rw,relatime,fd=15,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0 systemd-1 /sys/kernel/security autofs rw,relatime,fd=16,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0 systemd-1 /proc/sys/fs/binfmt_misc autofs rw,relatime,fd=17,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0 systemd-1 /sys/kernel/debug autofs rw,relatime,fd=18,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0 systemd-1 /dev/hugepages autofs rw,relatime,fd=19,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0 tmpfs /var/run tmpfs rw,relatime,mode=755 0 0
tmpfs /var/lock tmpfs rw,relatime,mode=775,gid=54 0 0
fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0
gvfs-fuse-daemon /home/kay/.gvfs fuse.gvfs-fuse-daemon rw,nosuid,nodev,relatime,user_id=2702,group_id=100 0 0
Kay
Quoted 10 lines · Greg KH
Quoted 9 lines · Kay Sievers
Quoted 7 lines · Greg KH
Quoted 3 lines
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.
Quoted 7 lines
Quoted 3 lines
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?
Vivek
Quoted 4 lines · Greg KH
Ah, that makes it easier. Paul and Vivek, any objection to this patch going in now?
Sounds reasonable.
Paul
Quoted 10 lines · Greg KH
Quoted 9 lines · Kay Sievers
Quoted 7 lines · Greg KH
Quoted 3 lines
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.
Quoted 6 lines
Quoted 3 lines
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?
Just to get an idea, here is the current output on a systemd system:
/dev/sda3 /home/kay/work ext3 rw,noatime,errors=continue,user_xattr,acl,barrier=0,data=writeback 0 0 devtmpfs /dev devtmpfs rw,relatime,size=1965252k,nr_inodes=491313,mode=755 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
tmpfs /dev/shm tmpfs rw,relatime 0 0
devpts /dev/pts devpts rw,relatime,mode=600 0 0
tmpfs /cgroup tmpfs rw,nosuid,nodev,noexec,relatime,mode=755 0 0
cgroup /cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd 0 0 systemd-1 /dev/mqueue autofs rw,relatime,fd=15,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0 systemd-1 /sys/kernel/security autofs rw,relatime,fd=16,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0 systemd-1 /proc/sys/fs/binfmt_misc autofs rw,relatime,fd=17,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0 systemd-1 /sys/kernel/debug autofs rw,relatime,fd=18,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0 systemd-1 /dev/hugepages autofs rw,relatime,fd=19,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0 tmpfs /var/run tmpfs rw,relatime,mode=755 0 0
tmpfs /var/lock tmpfs rw,relatime,mode=775,gid=54 0 0
fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0
gvfs-fuse-daemon /home/kay/.gvfs fuse.gvfs-fuse-daemon rw,nosuid,nodev,relatime,user_id=2702,group_id=100 0 0
Kay
Quoted 10 lines · Greg KH
Quoted 9 lines · Kay Sievers
Quoted 7 lines · Greg KH
Quoted 3 lines
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.
Quoted 7 lines
Quoted 3 lines
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?
Vivek
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 15 lines · Vivek Goyal
Quoted 14 lines · Greg KH
Quoted 12 lines · Kay Sievers
Quoted 7 lines · Greg KH
Quoted 3 lines
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.
Quoted 8 lines
Quoted 3 lines
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.
Jan
Quoted 15 lines · Vivek Goyal
Quoted 14 lines · Greg KH
Quoted 12 lines · Kay Sievers
Quoted 7 lines · Greg KH
Quoted 3 lines
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.
Quoted 8 lines
Quoted 3 lines
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.
Jan
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 22 lines · Jan Safranek
Quoted 21 lines · Vivek Goyal
Quoted 10 lines · Greg KH
Quoted 9 lines · Kay Sievers
Quoted 7 lines · Greg KH
Quoted 3 lines
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.
Quoted 7 lines
Quoted 3 lines
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.
Quoted 7 lines
Quoted 2 lines
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
Quoted 22 lines · Jan Safranek
Quoted 21 lines · Vivek Goyal
Quoted 10 lines · Greg KH
Quoted 9 lines · Kay Sievers
Quoted 7 lines · Greg KH
Quoted 3 lines
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.
Quoted 7 lines
Quoted 3 lines
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.
Quoted 7 lines
Quoted 2 lines
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
Quoted 9 lines · Greg KH
Quoted 8 lines · Paul Menage
Quoted 6 lines · Greg KH
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.
Quoted 7 lines
Quoted 3 lines
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
A message that is not in the archive (sent off-list or not yet received): AANLkTinsd2gWOHb3w9gzvKO5vdwLBT7DZOY+2xCUz_5_-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Quoted 18 lines · Dhaval Giani
Quoted 9 lines · Greg KH
Quoted 8 lines · Paul Menage
Quoted 6 lines · Greg KH
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.Quoted 7 lines
Quoted 3 lines
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?
Quoted 5 lines
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
_______________________________________________
Containers mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/containers
Quoted 18 lines · Dhaval Giani
Quoted 9 lines · Greg KH
Quoted 8 lines · Paul Menage
Quoted 6 lines · Greg KH
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.Quoted 7 lines
Quoted 3 lines
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?
Quoted 5 lines
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
A message that is not in the archive (sent off-list or not yet received): AANLkTimm9XGvK2H55V7N76JPU05iHk_dY5JjOLifQTsr-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Quoted 25 lines · Kay Sievers
Quoted 18 lines · Dhaval Giani
Quoted 9 lines · Greg KH
Quoted 8 lines · Paul Menage
Quoted 6 lines · Greg KH
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.Quoted 7 lines
Quoted 3 lines
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?
Quoted 5 lines
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.
Quoted 4 lines
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
Quoted 25 lines · Kay Sievers
Quoted 18 lines · Dhaval Giani
Quoted 9 lines · Greg KH
Quoted 8 lines · Paul Menage
Quoted 6 lines · Greg KH
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.Quoted 7 lines
Quoted 3 lines
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?
Quoted 5 lines
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.
Quoted 4 lines
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
A message that is not in the archive (sent off-list or not yet received): AANLkTi=OMaKuk+ReeqCfBGes76BjKYyUdqxPOQfH8EcZ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Quoted 26 lines · Dhaval Giani
Quoted 25 lines · Kay Sievers
Quoted 23 lines · Dhaval Giani
Quoted 9 lines · Greg KH
Quoted 8 lines · Paul Menage
Quoted 6 lines · Greg KH
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.Quoted 7 lines
Quoted 3 lines
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.
Quoted 7 lines
Quoted 4 lines
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
Quoted 26 lines · Dhaval Giani
Quoted 25 lines · Kay Sievers
Quoted 23 lines · Dhaval Giani
Quoted 9 lines · Greg KH
Quoted 8 lines · Paul Menage
Quoted 6 lines · Greg KH
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.Quoted 7 lines
Quoted 3 lines
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.
Quoted 7 lines
Quoted 4 lines
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
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 3 lines · Greg KH
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.
Quoted 3 lines
Or should I apply it to my driver-core one?
That sounds like an OK option too.
Paul
Quoted 3 lines · Greg KH
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.
Quoted 3 lines
Or should I apply it to my driver-core one?
That sounds like an OK option too.
Paul
A message that is not in the archive (sent off-list or not yet received): AANLkTimmAfhw7WhPHHU6d4izkzvp2oxOSzNN8JjNu_nU-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Quoted 5 lines · Paul Menage
Quoted 3 lines · Greg KH
Ok, again, after all of this, who is going to be applying this patch to their tree for the .36 merge window?
Quoted 7 lines
There's no specific cgroups tree - cgroups patches generally go via akpm.
Quoted 3 lines
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
Quoted 5 lines · Paul Menage
Quoted 3 lines · Greg KH
Ok, again, after all of this, who is going to be applying this patch to their tree for the .36 merge window?
Quoted 7 lines
There's no specific cgroups tree - cgroups patches generally go via akpm.
Quoted 3 lines
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
A message that is not in the archive (sent off-list or not yet received): [email protected]
Dhaval Giani
Acked-byQuoted 9 lines · Greg KH
Quoted 8 lines · Paul Menage
Quoted 3 lines · Greg KH
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.
Quoted 1 line
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
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.
while I am not a maintainer, from the libcgroup side at least,
Quoted 4 lines
thanks,
greg k-h
Paul Menage
Acked-byQuoted 3 lines · Greg KH
Wonderful, can I get some acks from the cgroups maintainers? I'll gladly take it through my tree.
Sure.
Paul
Dhaval Giani
Acked-byQuoted 9 lines · Greg KH
Quoted 8 lines · Paul Menage
Quoted 3 lines · Greg KH
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.
Quoted 1 line
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
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.
while I am not a maintainer, from the libcgroup side at least,
Quoted 4 lines
thanks,
greg k-h
A message that is not in the archive (sent off-list or not yet received): AANLkTi=d1-Uf4TeyvMH3evo91zPWjbincij=HC0ny0Ym-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Quoted 15 lines · Dhaval Giani
Quoted 14 lines · Greg KH
Quoted 12 lines · Paul Menage
Quoted 3 lines · Greg KH
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.
Quoted 3 lines
Or should I apply it to my driver-core one?
That sounds like an OK option too.
Quoted 7 lines
Quoted 3 lines
Wonderful, can I get some acks from the cgroups maintainers? I'll gladly take it through my tree.
while I am not a maintainer, from the libcgroup side at least,
Acked-by Dhaval Giani <[email protected]>
Thanks, I've added this to the patch.
greg k-h
Quoted 15 lines · Dhaval Giani
Quoted 14 lines · Greg KH
Quoted 12 lines · Paul Menage
Quoted 3 lines · Greg KH
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.
Quoted 3 lines
Or should I apply it to my driver-core one?
That sounds like an OK option too.
Quoted 7 lines
Quoted 3 lines
Wonderful, can I get some acks from the cgroups maintainers? I'll gladly take it through my tree.
while I am not a maintainer, from the libcgroup side at least,
Acked-by Dhaval Giani <[email protected]>
Thanks, I've added this to the patch.
greg k-h
Paul Menage
Acked-byQuoted 3 lines · Greg KH
Wonderful, can I get some acks from the cgroups maintainers? I'll gladly take it through my tree.
Sure.
Paul
A message that is not in the archive (sent off-list or not yet received): AANLkTi=Vrax+ob87uiDzeMxOmuDNYUWnDKG0jpfQppAp-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Quoted 8 lines · Paul Menage
Quoted 3 lines · Greg KH
Wonderful, can I get some acks from the cgroups maintainers? I'll gladly take it through my tree.
Sure.
Acked-by Paul Menage <[email protected]>
Wonderful, now queued up.
greg k-h
Quoted 8 lines · Paul Menage
Quoted 3 lines · Greg KH
Wonderful, can I get some acks from the cgroups maintainers? I'll gladly take it through my tree.
Sure.
Acked-by Paul Menage <[email protected]>
Wonderful, now queued up.
greg k-h