Re: [LAD] [ANNOUNCE] Safe real-time on the desktop by default; Desktop/audio RT developers, read this!

On Sat, 20.06.09 03:42, Lee Revell (rlrevell@email-addr-hidden-job.com) wrote:

> > Uh. I thought about that. Not sure if we really should do that
> > though. In many cases, the app's IO callback might not really be that
> > well suited for execution in RT. And then it might end up being killed
> > by RLIMIT_RTTIME or so. Dunno. Maybe that would not even be a problemn
> > and we could just make all IO threads RT at prio 1 or so. I am a bit
> > afraid that such a thing might backfire and we fuck up the scheduling
> > for everyone else too.
>
> Sorry if this is too many questions, i have read the Pulse code and
> the LKML thread and was wondering:
>
> I was under the impression that SCHED_RESET_ON_FORK was needed to
> safely enable RT mode in Pulse because Pulse runs untrusted client
> code. If that's not the case then why is it needed?

PA runs as user process. That's why this is needed. If a process is a
user process the user can do with it whatever he wants, in the PA case
this is even especially easy since all he needs to do is load some
module he wrote into the daemon.

> What does RealtimeKit set the RR interval to? IIRC the default is
> 100ms, seems like this could cause desktop interactivity issues. What
> determines the upper bound on the amount of work Pulse's RT threads
> can do?

We leave the RR interval at the default. I have some doubts that
fiddling with the RR interval is a good idea. First of all the API to
do that is messy and changed across kernel versions a few
times. Secondly, rtkit is not really useful beyond desktop media
stuff, and a desktop media application that wants to take a
substantial CPU share while being RT (where the interval would matter)
is uh, suspicious to say the least.

The CPU time is limited by RLIMIT_RTTIME and also simply by the fact
that on system overload (the definition of which can be configured in
rtkit) the RT threads are demoted.

I mean, if fiddling with the rr interval turns out to be necessary, we
can still add an interfaces this. Dunno. I kinda have the idea that
this is mostly a theoretical question anyway, since at least in the
audio case in the usual case only one process is runnable anyway, ...

If someone wants this, and has a good use case we can certainly add
this, but I'd not think too much about stuff we don't need right now.

> Without mlock(), what happens when the SCHED_RR thread starts taking
> page faults? AFAICT, it will be scheduled out, but as long as it has
> time slice left, it will be immediately rescheduled.

To my knowledge while the process is waiting for IO to complete for
the page fault other processes will be scheduled. The time
spent in page faults is not counted as process time.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev