[systemd-devel] [HEADSUP] cgroup changes

[Kok, Auke-jan H]

On Fri, Jun 21, 2013 at 1:10 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> On Fri, 21.06.13 12:59, Kok, Auke-jan H (auke-jan.h.kok at intel.com) wrote:
>
>> > http://lists.freedesktop.org/archives/systemd-devel/2013-June/011388.html
>> >
>> > Here's an update and a bit on the bigger picture:
>>
>> Thanks for doing this - I am really looking forward to seeing this all
>> take shape, and I hope to be able to leverage this in the future :^)
>>
>> All the points below are great, and problems that I've encountered in
>> the past have all hinted towards this being the right way forward.
>>
>> #2 below has my interest - when you have some ideas about how the API
>> will look I'd like to review it and match against our use cases...
>
> Point #2 is precisely about not having APIs for this... ;-)
>
> So, in the future, when you have some service, and that service wants to
> alter some cgroup resource limits for itself (let's say: set its own cpu
> shares value to 1500), this is what should happen: the service should
> use a call like sd_pid_get_unit() to get its own unit name, and then use
> dbus to invoke SetCPUShares(1500) for that service. systemd will then do
> the rest. (*)
>
> Lennart
>
> (*) to make this even simpler we have been thinking of defining a new
> "virtual" bus object path /org/freedesktop/systemd1/self/ or so which
> will always points to the callers own unit. This would be similar to
> /proc/self/ which also points to its own PID dir for each
> process... With that in place you could then set any resource setting
> you want with a single bus method call.

This is fine for applications that manage themselves, but I'm seeing
more interest in use cases where we want external influence on cgroup
hierarchies, for instance:

- foreground/background priorities - a window manager marks background
applications and puts them in the freezer, changes oom_score_adj so
that old apps can get automatically cleaned up in case memory
availability is low.
- detecting runaway apps and taking cpu slices away from them.
- thermally constraining classes of applications

Those would be tasks that an external process would do by manipulating
properties of cgroups, not something each task would do on it's own.

Do you suggest these manipulations should be implemented without high
level systemd API's and the "controller" just manipulates the cgroups
directly?

Auke