Relationship between cgroup hierarchy and slice names

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

I'm trying to override the parent slice of a certain slice unit so I can reorganize the cgroup hierarchy. I looked into overriding the "Slice" property to set the containing slice of the unit, but it seems that property does not do anything for slices because the location in the cgroup hierarchy and parent are already set by the unit name. The documentation says the unit name is composed of a series of words separated by dashes, where each word represents a directory in the cgroup hierarchy. If the unit name was independent from the location of the slice in the cgroup hierarchy, then I would imagine that would make overriding the parent slice possible. I tried to find the reason why the slice unit name must strictly match the cgroup hierarchy, but I could not come up with an answer after searching online and thinking about it myself.
One possibility for why the slice name must match the hierarchy could be naming conflicts. If there are two slices with the same name but in different cgroups, they could conflict with each other. But I decided this could not be the case, since developers could just avoid the conflicts by using the slice naming convention as a convention instead of following it as a hard rule. Furthermore, there are several unit types like scopes and services which can be organized in the cgroup hierarchy like slices, but don't follow the same naming rule. If it was decided that naming conflicts in relation to the cgroup hierarchy would not pose a problem for these other units, then why was it decided for slices?
Another possibility that comes to mind is that naming slices this way makes using them easier, since developers would not have to put an extra Slice property on the unit. It would also be possible to tell the location of a slice in the cgroup hierarchy just by looking at the name. But would people sacrifice the capability for users to reorganize and override the cgroup hierarchy, for some convenience?
Another possibility is aesthetic reasons, but then again that would be enforcing a personal decision on a community, which I don't think would happen.

Is there another way to override the location of a slice in the cgroup hierarchy? And what is the reason why slice names have to correspond with their location in the cgroup hierarchy?

[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux