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
