On Mon, 14.02.11 10:58, Andrey Borzenkov (arvidj...@mail.ru) wrote: > > On Mon, Feb 14, 2011 at 6:12 AM, fykc...@gmail.com <fykc...@gmail.com> wrote: > > Hi Lennart, > > Thanks for the explanation. > > IMHO, To re-enable user session 'cpu' sorting: > > a) Desktop distributions disable GROUP_RT in the kernel, then no > > rt_bandwidth, all RT-apps can be fully administrated under rtkit. > > Or b) cpu cgroup controller should default make sub-cgroups share > > rt_bandwidth with their parent. > > RT is about determinism. You need to ensure that task will be able to > respond in fixed time. If you allow arbitrary, unknown in advance, > number of tasks share the same limited CPU share, you simply kill > determinism.
Well, RT on Linux is not deterministic really. It just means that processes can monopolize the CPU for a while. The general approach in RT on Linux is "remove scheduling latency where we find it". Such an approach can never guarantee determinism. And I don't think anything else would be realistic to do. > Personally I think that RT should be restricted to limited number of > tasks that are known in advance; then it is responsibility of > administrator to allocate their CPU share according to requirements. Well, I think this might be an approach for technical appliances, but not really for general purpose stuff such as audio where we need a very weak definition of RT only. Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
