[systemd-devel] [HEADSUP] cgroup changes

[Andy Lutomirski]

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