[systemd-devel] dbus interface for disabling default cgroups

[Lennart Poettering]

On Mon, 14.02.11 00:38, Daniel Poelzleithner (poelzi at poelzi.org) wrote:

> On 02/13/2011 10:36 PM, Lennart Poettering wrote:
> 
> 
> > Note that pam_systemd in git now explicitly resets the "cpu" cgroup of
> > all sessions to the root group since otherwise RT scheduling will not be
> > available for any user daemons. This is a general limitation of the
> > "cpu" scheduler right now, and makes it impractical to muck around with
> > it for generic sessions.
> 
> I stumbled on this one too, but got it fixed by giving the most cgroups
> a rt_sched_slice of 1. this way they can be set to rt and then, move the
> process to a group with more rt slice if there is a rule to move it
> there.

I am not sure what "rt_sched_slice" is supposed to be, but in case you
are referring to cpu.rt_runtime_us:

That's not a fix. That's a hack.

The time slices need to add up and you break assumptions in the programs
with that. The us you hand out need to add up. And if you limit the RT
runtime to 1us per 1s then this is barely enough time to do almost
anything. Usually, if apps ask for RT they actually want to do
non-trivial work in that timeslice too... The whole point of RT sched is
too be able to monopolize the CPU until the app gives it up
voluntarily. Mucking with cpu.rt_runtime_us intreferes with that and
allows to install upper limits to the RT time the apps get, in a "safety
net" sense, to ensure that apps don't monopolize the CPU for too
long. But if you unconditionally just set this value to the smallest
value possible then your upper limit basically makes RT entirely
useless.

> >> org.freedesktop.systemd1.Manager.ChangeController(string subsystem,
> >> boolean enable, boolean clear)
> > 
> > Nah, if at all then the controller property should just become
> > writable. But to be frank I am not sure we actually want to make this
> > changeable at runtime.
> 
> If the admin decides he wants to run a program that optimizes the system
> better, he already made this decision.

Well, if he doesn't want systemd to much with the "cpu" controller, then
he can easily disable that in a config file. 

Lennart

-- 
Lennart Poettering - Red Hat, Inc.