[systemd-devel] set rr scheduler failed with cpushares

[Lennart Poettering]

On Wed, 03.12.14 22:13, Umut Tezduyar Lindskog (umut at tezduyar.com) wrote:

> Hi,
> 
> 
> On Tue, Dec 2, 2014 at 7:12 PM, Lennart Poettering
> <lennart at poettering.net> wrote:
> > On Mon, 17.11.14 23:46, WaLyong Cho (walyong.cho at samsung.com) wrote:
> >
> >> Hello,
> >>
> >> I'd made two different services. One has *CPUSchedulingPolicy=rr* and
> >> the others has *CPUShares=*.
> >>
> >> Could anyone help me?
> >
> > If CPUShares= is set this has the effect that the service and all
> > services in the same slice will be have the "cpu" cgroup controller
> > turned on. Unfortunately this has the effect that RT scheduling will
> > be unavailable then, unless an explicit RT budget is configured for
> > that specific cgroup. This is something systemd cannot be used for
> > nicely however, as we don't expose high-level controls for the RT
> > budget.
> >
> > The RT budget is configured in the cpu.rt_runtime_us and
> > cpu.rt_period_us cgroup attributes. You can write to them from
> > ExecStartPre= for example using the %c specified.
> 
> Wouldn't it be against the idea of "access to control groups should go
> through systemd"?

Yes, it is against that idea, absolutely.

> Is this something you are recommending until we start exposing RT
> parts of the cgroups, or?

No. It's more difficult: the kernel API is awful here (since it really
shouldn't break RT without explicit initialization), and it will
reappear in a very different form in the unified hierarchy. We will
however only expose it as soon as we know how it looks in the new
hierarchy.

Until then things are not pretty: we won't expose firendly options for
them, hence there's really no other way than hackishly writing to the
attributes directly, even though this is clearly something that will
stop working as soon as the unified hierarchy is adopted.

Lennart

-- 
Lennart Poettering, Red Hat