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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
