[systemd-devel] [HEADSUP] cgroup changes

[Lennart Poettering]

On Fri, 21.06.13 14:47, Kok, Auke-jan H (auke-jan.h.kok at intel.com) wrote:

> >> Do you suggest these manipulations should be implemented without high
> >> level systemd API's and the "controller" just manipulates the cgroups
> >> directly?
> >
> > All changes to cgroup attributes must go through systemd. If the WM
> > wants to freeze or adjust OOM he needs to issue systemd bus calls for
> > that.
> >
> > The run-away stuff I can't follow? the kernel will distribute CPU
> > evenly among running apps if all want it, so not seeing why there's more
> > monitoring needed.
> >
> > The thermal stuff is probably best done in-kernel i guess... Too
> > dangerous/subject-to-latency for userspace, no?
> 
> Only userspace can distinguish between e.g. a foreground and
> background application (WM) and decide that CPU consumption of certain
> apps in the background is excessive, and throttle it down further,
> which is somewhat similar to using freezer to just SIGSTOP them
> entirely basically.

Yes, userspace can do that via systemd, there will be high-level
operations on the bus for this. For example: SetCPUShares() to alter the
cpu.shares value, and so on. This method call will do much more though
thatn just write this value. One of the complexities of the cgroup stuff
here is that adding a unit to a controller like "cpu" means you have to
do the same for all its immediately siblings (i.e. other units in the
same slice) plus all its parent slices (and recurisvely their
siblings). Why? Because otherwise you might end up granting the service
that is in the "cpu" controller the same amount of CPU *in total* as the
other services in the same slice get *individually* for each
process. And that would be grossly unfair...

> Thermal throttling from userspace allows you to distinguish between
> "never make my SETI turn the fan on" and "throttle the entire system
> when I reach high fan speeds". You can't do that in the kernel. [1]
> Arguably this could be done in-task and not by an external controller,
> but you're still trusting the task to do the right thing, which may
> not be something you want to do.

So, if userspace needs to communicate something to kernel space about
what kind of cooling stragegy it would prefer and that is done via
cgroups, them I am sure we can add similar high-level per-unit control
calls to systemd, too.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.