[systemd-devel] dbus interface for disabling default cgroups

[Lennart Poettering]

On Mon, 14.02.11 11:41, Daniel Poelzleithner (poelzi at poelzi.org) wrote:

> On 02/14/2011 10:42 AM, Lennart Poettering wrote:
> 
> 
> >> 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.
> 
> Hell yeah. I got hack rules to fix the bad behaviour of gnome and kde
> because they do not set the setpgid on started task as they are supposed
> to...
> Optimising a system seems like one big workaround ;-)

I am not sure what you mean by "do not set the setpgid"? Do you want
gnome-session to become its own session or the desktop services
themselves?

> > 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.
> 
> Of course 1ms is useless. Thats the point. What processes do a normal

So, are you setting things to 1us, or 1ms?

> user run that need realtime rt. I know exactly 2, thats pulseaudio and
> jackd. For both exist rules that move the process to a group with higher
> cpu.rt_runtime_us, enough that they should work properly but can not
> bring down your system. It's enough to start, but not enough to use.
> Maybe I will add a rule that matches rt tasks and move them to a special
> group, I will think about that.

Well, ideally your entire pipeline should be RT if you do audio. For
example, all Jack clients should have an RT thread. And that's already
quite a few programs.

> If you are doing highend audio for example, the default desktop
> configuration will not suite you, so you need simply to switch to an
> configuration that fits better. Thats one root dbus call away, or with
> the new gui one click and password. It is simply not possible to
> configure a system that will fit all workloads.

Well, I don't buy that. I am working on something that is equally well
suitable for all uses. I don't think that scalability in your solutions
is impossible. The Linux kernel itself has already shown that it scales
equally well to supercomputers and embedded devices.

The need for configuration is a bad thing, not a good thing. Where we
can we should create systems that just work.

> > Well, if he doesn't want systemd to much with the "cpu" controller, then
> > he can easily disable that in a config file. 
> 
> Then the package install scripts will have to change that...

Thankfully most distributions don't allow mucking around with other
package's configurations from the install scripts of a different
package.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.