On Mon, 14.02.11 11:41, Daniel Poelzleithner ([email protected]) 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. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
