[systemd-devel] dbus interface for disabling default cgroups

[Daniel Poelzleithner]

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 ;-)

> 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
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.

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, 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...


Daniel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20110214/e8cf19af/attachment.pgp>