[pulseaudio-discuss] Rtkit and PulseAudio rlimit_rttime mismatch

[Lennart Poettering]

On Mon, 30.06.14 11:16, Felipe Sateler (fsateler at debian.org) wrote:

> 
> On Fri, Jun 27, 2014 at 4:37 AM, David Henningsson
> <david.henningsson at canonical.com> wrote:
> > Hi,
> >
> > Ricardo just noticed that a bug fixed in rtkit 0.11 causes a mismatch
> > between PulseAudio and RtKit.
> >
> > In short, PulseAudio sets its default RLIMIT_RTTIME to one second, and rtkit
> > by default refuses to give realtime priority to anything above 200 ms.
> >
> > So, should we change rtkit to allow an RLIMIT_RTTIME of one second, or
> > modify PulseAudio to have itself killed after 200 ms of rtprio? Opinions?
> 
> Also, how does rtkit interoperate with the newer systemd without
> ControlGroup stanzas?
> 
> >
> > (And btw, any chance we can deprecate rtkit altogether sometime, given a
> > recent systemd and kernel?)
> 
> If I understand this correctly, this would entail runnning pulseaudio
> as a user service. But this does not seem to work reliably: I have not
> succeeded in having services started by systemd talk to the dbus
> started by the X session. But perhaps I'm doing something wrong, and
> with too old a stack (systemd 208, dbus 1.8.4).

Heya, sorry for not responding to this thread earlier, somehow missed it
entirely.

The thing with rtkit is a bit messy right now. The rt cgroup hookup in
the kernel is a fucked up so far, and it is not clear how or when it
will be fixed. Because of this uncertain situation we are not exposing
any rt cgroup props in systemd but until that happens rtkit is a bit in
an unhappy spot, since without rt privs it cannot do its job.

I am not entirely sure if there's still the need to keep rtkit around if
one day the kernel (and then systemd) get fixed. I mean, if we could
safely assign each user a fixed RT budget (and that means without taking
that budget away from other users), then I would feel much easier about
just giving all users RT rights. That said, allowing users to dominate
the CPU so massively and otherwise unrestricted sounds like quite a
massive change (and step backwards) from the current behaviour, where
rtkit grants RT privs only very selectively to specific threads, after
verifying with polkit. It also makes sure this cannot leak to other
processes, and keeps an eye on it with an rt watchdog. This all appears
to be quite a benefit in my eyes, and reason enough to keep it, and not
just assign each user that RT budget unrestricted.

That all said, I am tempted to just merge rtkit (or something
equivalent) as a mini-service into systemd, so that it ceases to be an
independent package people have to install, but is just soemthing that
is always there.

Lennart

-- 
Lennart Poettering, Red Hat