Re: [LAD] Kontakt Spikes

From: Michael Ost <most@email-addr-hidden>
Date: Mon Oct 10 2011 - 20:55:40 EEST

On 10/08/2011 04:02 AM, Clemens Ladisch wrote:
> Michael Ost wrote:
>> The higher priority threads in the system are:
>> ...
>> * IRQ8 (rtc) - FIFO/99
>
> Why does this interrupt get such a high priority?
> (Not that it matters as I don't expect it to be used at all ...)

No, it isn't used. This is just a by-product of the rtirq script that we
run at startup.

Have you ever seen "migration" or "watchdog" hold the CPU for any length
of time? I was curious about "migration" since

/proc/sys/kernel/sched_migration_cost = 500000

so I set cpu affinity on the threads, but it didn't change things.

>> Are there issues with memory mapping, that can block other unrelated
>> threads?
>
> Then you would have seen page faults.

Yes, that was what I figured too. Thanks for the confirmation.

>> There do appear to be "involuntary context switches" (as reported by
>> getrusage) when the spikes happen. This makes it seem like the
>> scheduler is interrupting our threads. But how do you figure out why
>> that is happening? [...] All of the 5 processing threads are
>> SCHED_RR/76. [...] Are there just too danged many SCHED_RR threads
>> fighting for two cores?
>
> RR means Round Robin, i.e., all threads with the same priority get
> an equal amount of CPU without much delay, so the scheduler has to
> switch between them quite often. RR is intended for threads that must
> make some progress continuously. (See "man sched_setscheduler" and
> especially "man sched_rr_get_interval".)
>
> If you want to run a thread until it has finished for now, use
> SCHED_FIFO.
>
> I assume it is your intention that all those threads have equal priority
> (which means to the kernel "don't care which one of them gets executed
> first").

SCHED_RR is what we want. Our realtime audio processing (and midi input)
threads all need to be able to run. They just must not be interrupted
ever by GUI or user level threads.

I'm not totally clear on how SCHED_RR and SCHED_FIFO relate though.
Would (a) a SCHED_RR/50 thread be run ahead of a SCHED_FIFO/49 thread?
And would (b) a SCHED_RR/50 thread interrupt a running SCHED_FIFO/49 thread?

Thanks for your reply,

Michael Ost
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Tue Oct 11 00:15:02 2011

This archive was generated by hypermail 2.1.8 : Tue Oct 11 2011 - 00:15:02 EEST