Re: [patch] IRQ threads

[Karim Yaghmour <karim@opersys.com>]

Scott Wood wrote:
> I have attached a patch for implementing IRQ handlers in threads, for
> latency-reduction purposes.  It requires that softirqs must be run in
> threads (or else they could end up running inside the IRQ threads,
> which will at the very least trigger bugs due to in_irq() being set). 
> I've tested it with Ingo's voluntary-preempt J7 patch, and it should
> work with the TimeSys softirq thread patch as well (though you might
> get a conflict with the PF_IRQHANDLER definition; just merge them
> into one).

My experience with clients who have been using TimeSys' stuff has been
abysmal. The fact of the of the matter is that most people who used
this were practically locked-in to TimeSys' services, unable to download
anything "standard" off the net and using it with their kernel. In one
example, we had to ditch the kernel the client got from TimeSys because
we had spent 10+ hours trying to get LTT to work on it without any
success whatsoever.

As I had said on other lists before, I don't see the point of creating
that much complexity in the kernel in order to try to shave-off a little
bit more off of the kernel's interrupt response time. The fact of the
matter is that neither this patch nor most of the other patches suggested
makes the kernel truely hard-rt. These patches only make the kernel
respond "faster". If you really need hard-rt, then you should be using
the Adeos nanokernel. With Adeos, you can even get a hard-rt driver
without using RTAI or any of the other rt derivatives.

Karim
-- 
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || karim@opersys.com || 1-866-677-4546