[systemd-devel] [lennart at kemper.freedesktop.org: [systemd-commits] src/pam-module.c]

[Lennart Poettering]

On Mon, 14.02.11 10:58, Andrey Borzenkov (arvidjaar at mail.ru) wrote:

> 
> On Mon, Feb 14, 2011 at 6:12 AM, fykcee1 at gmail.com <fykcee1 at 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.