[systemd-devel] Rationale for mirroring cpu and systemd cgroup subsystems

Lennart Poettering lennart at poettering.net
Wed Nov 5 10:10:09 PST 2014


On Wed, 05.11.14 16:00, Umut Tezduyar Lindskog (umut at tezduyar.com) wrote:

> On Wed, Nov 5, 2014 at 2:05 PM, Lennart Poettering
> <lennart at poettering.net> wrote:
> > On Wed, 05.11.14 13:41, Umut Tezduyar Lindskog (umut at tezduyar.com) wrote:
> >
> >> Hi,
> >>
> >> What is the reasoning for not joining cpu subsystem with systemd subsystem?
> >>
> >> There are couple ways you can mirror [1] cpu and systemd subsystems
> >> and doing so can result completely different cpu bandwidth for
> >> processes.
> >>
> >> I am wondering why we don't mirror them by default.
> >
> > Because simply enabling a "cpu" controller for a unit already has
> > effects on the processes running it. For example, you don't get RT
> > anymore, and the general scheduling is altered to schedule your entire
> > group evenly against the all groups on the same level.
> 
> Doesn't it make sense to turn it on by default and let users wanting
> RT disable it? Seems like this was the case at some point -
> http://www.freedesktop.org/wiki/Software/systemd/MyServiceCantGetRealtime/
> (Very much outdated article, we don't have ControlGroup= anymore)

Yeah, I really need to update that article.

Generally we should try hard to keep the tree minimal. Resource
control enforcement is not free, and hence it should be opt-in, not
opt-out. This is something Tejun pretty explicitly asked us for: he
wants the most shallow tree that does what is needed.

> > systemd will "mirror" a cgroup in the "cpu" hierarchy as soon as you
> > set a property on it that requires the "cpu" or "cpuacct" hierarchy,
> > for example CPUAccounting=, CPUShares= or CPUQuota.
> 
> You can turn on mirroring during runtime but as far as I know there is
> no way going back without rebooting right?

In current versions it should correctly turn mirroring off again when
you reset the props to their defaults.

Lennart

-- 
Lennart Poettering, Red Hat


More information about the systemd-devel mailing list