[systemd-devel] threads and cgroups

[Lennart Poettering]

On Wed, 12.02.14 11:28, Allmeroth, Robert (robert.allmeroth at harman.com) wrote:

> Hi,
> 
> I read a lot about the new cgroup concept of the kernel/systemd.
> I understand the logic behind it and why systemd wants to be the MCP of it.
> But I miss information how threads are handled.
> 
> Example:
> Due to performance reasons we arrange components with various profiles into one executable.
> Assume a splash-animation on startup, audio-management, CAN, key input etc. Some of them should be
> protected by a realtime cgroup - others not.
> 
> Right now we are able to put the whole unit/process into one cgroup with systemd mechanisms (I like the slice concept :))
> Named threads can be handled by extra tooling, e.g. invoked via ExecStartPost, managing the threads/cgroups directly 
> 
> Problems will arise if manual management is impossible in future implementations.
> Is there a systemd concept if and/or how threads living inside of processes can be assigned to separate cgroups?
> 
> Best regards
>   Robert
> 
> PS: resources I used:
> http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/
> http://lists.freedesktop.org/archives/systemd-devel/2013-June/011521.html

The plan by the kernel guys is to not allow cgroup management on threads
anymore, only entire processes. The APIs in systemd reflect this
decision by the kernel guys: you cannot arrange individual threads for
organization by cgroups. 

As a replacement for this in the short-term people should use
pthread_setsched*(). Of course, this does not allow grouping, only
assignment of scheduling parameters per-trhead. The plan is to add a new
API for that in the longer run, but it is unlikely to involve cgroups or
anything, but be a specific API for scheduling and nothing else, and not
be exposed in any file system.

Basically, in the cgroups "version 2.0" design, this feature is gone.

Sorry if this is disappointing.

Lennart

-- 
Lennart Poettering, Red Hat