On 06/21/2013 10:36 AM, Lennart Poettering wrote:
2) This hierarchy becomes private property of systemd. systemd will set it up. Systemd will maintain it. Systemd will rearrange it. Other software that wants to make use of cgroups can do so only through systemd's APIs. This single-writer logic is absolutely necessary, since interdependencies between the various controllers, the various attributes, the various cgroups are non-obvious and we simply cannot allow that cgroup users alter the tree independently of each other forever. Due to all this: The "Pax Cgroup" document is a thing of the past, it is dead.
If you are using non-trivial cgroup setups with systemd right now, then things will change for you. We will provide you with similar functionality as before, but things will be different and less low-level. As long as you only used the high-level options such as CPUShares, MemoryLimit and so on you should be on the safe side.
Hmm. This may be tricky for my use case. Here are a few issues. For all I know, they may already be supported (or planned), but I don't want to get caught.
1. I put all the entire world into a separate, highly constrained cgroup. My real-time code runs outside that cgroup. This seems to exactly what slices are for, but I need kernel threads to go in to the constrained cgroup. Will systemd support this?
2. I manage services and tasks outside systemd (for one thing, I currently use Ubuntu, but even if I were on Fedora, I have a bunch of fine-grained things that figure out how they're supposed to allocate resources, and porting them to systemd just to keep working in the new world order would be a PITA [1]).
(cgroups have the odd feature that they are per-task, not per thread group, and the systemd proposal seems likely to break anything that actually wants task granularity. I may actually want to use this, even though it's a bit evil -- my real-time thread groups have non-real-time threads.)
I think that what I want are something like sub-unit cgroups -- I want to be able to ask systemd to further subdivide the group for my unit, login session, or whatever. Would this be reasonable? (Another way of thinking of this is that a unit would have a whole cgroup hierarchy instead of just one cgroup.)
I think that the single-hierarchy model will require that I subdivide my user session so that the default sub-unit cgroup is constrained similarly to the default slice. I'll lose functionality, but I don't think this is a showstopper.
A different approach would be to allow units to (with systemd's cooperation) escape into their own, dynamically created unit. This seems kind of awful.
3. My code runs unprivileged, but it still wants to configure itself. If needed, I can write a little privileged daemon to handle the systemd calls.
I think I can get away without anything fancy if a unit (login session?) grant the right to manipulate sub-unit cgroups to a non-root user.
4. As mentioned, I'm on Ubuntu some of the time. I'd like to keep the same code working on systemd and non-systemd systems.
How hard would it be to run systemd as just a cgroup controller? That is, have systemd create its slices, run exactly one unit that represents the whole system, and let other things use the cgroup API.
[1] Some day, I might convert my code to use a session systemd instance. I'm not holding my breath, but it could be nice.
--Andy _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
