IRQ handler under load - slow response

[kurt.van.dijck@eia.be (Kurt Van Dijck)]

On Fri, Mar 25, 2011 at 09:46:43AM +0100, Arno Steffen wrote:
> 2011/3/24 Kurt Van Dijck <kurt.van.dijck@eia.be>:
> > On Thu, Mar 24, 2011 at 12:56:48PM +0100, Arno Steffen wrote:
> >> 2011/3/14 Kurt Van Dijck <kurt.van.dijck@eia.be>:
> >> > On Mon, Mar 14, 2011 at 02:26:35PM +0100, Arno Steffen wrote:
> 
> I get it working with your help. I see now threads for every IRQ I
> anounce to the system.
Good news. I'm in fact a bit curious to the results...
> Nevertheless it doesn't change the behaviour,
> even after increasing their prio. My assumption is: The kernel IRQs
> threads are processed fast, I do have the trouble on the user side of
> the IRQ handler.
> 
> The best performance I get, if all processes on my device are running
> in policy OTHER.
Just to update my memory: I think threaded-irq will give:
* less peak perfomance
* less average performance
* better 'worst' performance
ie. There should be much less jitter in the performance measurement.
> As soon as my code is running in FIFO or RR I have
> problems. If the IRQs-thread has higher priority it works better, but
> is far away from reliability of OTHER policy.
That's less good news.
I suppose you have enabled all relevant RT & preemptive options.
Then I'm out of ideas too.
> This is in opposite to
> all what I know about scheduling policies.
Ack.
> 
> Best regards
> Arno

Regards,
Kurt