On 10/08/2011 04:02 AM, Clemens Ladisch wrote:
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
Yes, that was what I figured too. Thanks for the confirmation.
>> There do appear to be "involuntary context switches" (as reported by
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,
Linux-audio-dev mailing list