Messages in this thread | | | Subject | Re: Attaching a cgroup subsystem to multiple hierarchies | From | Glyn Normington <> | Date | Fri, 7 Feb 2014 09:21:42 +0000 |
| |
Hi Michal
On 6 Feb 2014, at 18:59, Michal Hocko <mhocko@suse.cz> wrote:
> On Wed 05-02-14 14:39:52, Glyn Normington wrote: >> Reading cgroups.txt and casting around the net leads me to believe >> that it is possible to attach a cgroup subsystem (e.g. memory) to >> multiple hierarchies, but this seems to result in “mirrored” >> hierarchies which are automatically kept in step with each other - >> essentially it looks like the same hierarchy at multiple file system >> paths. >> >> Take the following interaction for example: >> >> \begin{verbatim} >> $ pwd >> /home/vagrant >> $ mkdir mem1 >> $ mkdir mem2 >> $ sudo su >> # mount -t cgroup -o memory none /home/vagrant/mem1 >> # mount -t cgroup -o memory none /home/vagrant/mem2 >> # cd mem1 >> # mkdir inst1 >> # ls inst1 >> cgroup.clone_children memory.failcnt ... >> # ls ../mem2 >> cgroup.clone_children inst1 memory.limit_in_bytes ... >> # cd inst1 >> # echo 1000000 > memory.limit_in_bytes >> # cat memory.limit_in_bytes >> 1003520 >> # cat ../../mem2/inst1/memory.limit_in_bytes >> 1003520 >> # echo $$ > tasks >> # cat tasks >> 1365 >> 1409 >> # cat ../../mem2/inst1/tasks >> 1365 >> 1411 >> >> Is this working as intended? > > Yes, it doesn't make any sense to have two different views on the same > controllers.
Then wouldn’t it be better for the second mount to fail?
> >> Is there some other way to attach a subsystem to *distinct* >> hierarchies? > > No. > >> Distinct hierarchies would allow distinct cgroups, distinct settings >> (e.g. memory.limit_in_bytes) and distinct partitions of the tasks in >> the system. > > Which one should be applied then?
Good question. All of them, I would say: the constraints due to distinct settings would be ANDed together.
The implementation would be more complex and less efficient as a subsystem's resources consumed by a process would need charging against each hierarchy to which the subsystem was attached.
I very much doubt this would be worth implementing and I’m not at all suggesting it.
> >> >> Note: I don’t have a good use for this function - I’m simply >> trying to reverse engineer the semantics of cgroups to get a precise >> understanding. > > I think there is no need to reverse engineer ;) > Documentation/cgroups/cgroups.txt in the kernel tree does give a decent > description IMO.
I disagree. For example, cgroups.txt does not clearly state whether or not a single subsystem may be attached to distinct hierarchies.
This seems to have caused confusion elsewhere. For example, Red Hat write “… a single subsystem can be attached to two hierarchies if both of those hierarchies have only that subsystem attached.” ([1]).
> > -- > Michal Hocko > SUSE Labs
Regards, Glyn
[1] See “Rule 2” on p. 10 of https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/pdf/Resource_Management_Guide/Red_Hat_Enterprise_Linux-6-Resource_Management_Guide-en-US.pdf-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |