Re: Using patch-2.6.33.7.2-rt30 increases latency and CPU usage?

[Grant Edwards <grant.b.edwards@gmail.com>]

On Tue, May 15, 2012 at 01:33:12PM -0400, Steven Rostedt wrote:
> On Wed, 2012-05-09 at 23:18 +0000, Grant Edwards wrote:
> 
> > I eventually figured out that my increased interrupt latency is due to
> > my ISR being run in a kernel thread instead of as a real ISR.  Adding
> > the IRQF_NODELAY flag gets me the same average latency I had without
> > the RT patch.  [It looks like that flag has a different name in 2.6.39
> > and later?]
> 
> Note, adding a IRQF_NODELAY is very dangerous. To keep the kernel
> fully preemptible (well mostly), spin-locks have been converted into
> mutexes. If the irq handler has one of these spinlocks that have been
> converted, it may schedule in the interrupt handler and crash the
> kernel. You can not schedule in interrupt context, which is why the
> RT kernel makes the interrupt handlers into threads.

Noted.  Since the IRQF_NODELAY approach still misses the deadline 2-3%
of the time, that approach is probably off the list anyway.  Right now
we're looking at using either FIQ interrupt or Xenomai.

> Also note, you may get better response if you up the interrupt
> thread's priority. Up it to 98, and you should see much better
> responses.

Thanks for the tip.  I'll keep that in mind for some other projects
that would need latency times in the 100-200us range, which should be
doable.

> Now I don't think you will make the 20us under load, but you won't do
> that in the non-RT patch either.

Right.  With the non-RT patch, the average response is about the same,
but the worst-case numbers are 2X-3X.

-- 
Grant