Re: [linux-audio-user] -rt IRQ handler priorities

From: Kjetil S. Matheussen <kjetil@email-addr-hidden>
Date: Wed May 10 2006 - 01:45:22 EEST

On Tue, 9 May 2006, Lee Revell wrote:

> On Tue, 2006-05-09 at 13:27 -0700, Kjetil S. Matheussen wrote:
>> On Tue, 9 May 2006, Lee Revell wrote:
>>
>>> On Tue, 2006-05-09 at 12:56 -0700, Kjetil S. Matheussen wrote:
>>>>
>>>> Then theres a latency problem in the kernel. A sleeping high priorioty
>>>> SCHED_FIFO thread must be woken up in time even if another lower
>>>> priority SCHED_FIFO thread is buzy-looping. And currently, unless the
>>>> softirq timer has priority 99, that condition can not be fullfilled.
>>>>
>>>> So, the softirq timer must run with priority 99.
>>>
>>> I think it's unusual to want a high priority SCHED_FIFO thread to be
>>> awakened by a timer. What are you trying to do?
>>>
>>
>> Well, the reason for stumble upon this problem is when I ported/tested
>> the general watchdog program "das_watchdog" from 2.4 to 2.6. For some
>> reason, it just didn't work. But after reading the instructions for
>> Florians rt_watchdog program, it became clear that the softirq
>> thread must have priority 99.
>>
>> But lets say that you have program with two SCHED_FIFO threads. One
>> of them is a high priority (between 2 and 98) timer that is only
>> used to signal other threads. The other SCHED_FIFO thread has priority
>> 1 and needs to run realtime for some reason, and it might not even be
>> a good reason. However, if that other thread have to do
>> some hard work, it stalls your high priority timer thread for a small
>> time, and your sleep-based timer suddenly becomes shaky.
>>
>
> Hmm, it sounds like a solution could be to separate timers that just
> wake up a process from ones that do actual work and run them in separate
> kernel threads.
>

I don't understand why you want that. To me (which
knows about nothing about how the kernel works), the solution to
the problem is crystal clear: The softirq timer needs to have the highest
priority, and the only thing the sofirq timer threads does is to
make sure threads that should be woken up are put into some kernel
schedule queue somehow. I don't understand why the softirq timer threads
should cause any latency problems, what does it do except scheduling
waiting threads?
Received on Wed May 10 04:15:03 2006

This archive was generated by hypermail 2.1.8 : Wed May 10 2006 - 04:15:03 EEST