Re: [PATCH] local_irq_disable removal

[Sven-Thorsten Dietrich <sdietrich@mvista.com>]

On Sun, 2005-06-12 at 01:44 +0200, Thomas Gleixner wrote:
> On Sat, 2005-06-11 at 13:51 -0700, Daniel Walker wrote:
> > On Sat, 11 Jun 2005, Ingo Molnar wrote:
> 
> > Interesting .. So "cli" takes 7 cycles , "sti" takes 7 cycles. The current 
> > method does "lea" which takes 1 cycle, and "or" which takes 1 cycle. I'm 
> > not sure if there is any function call overhead .. So the soft replacment 
> > of cli/sti is 70% faster on a per instruction level .. So it's at least 
> > not any slower .. Does everyone agree on that?
> 
> No, because x86 is not the whole universe
> 

Das Dehnt sich aus.

Even if there is a case of minimal expansion in the overhead on some
architecture, it may justify the effort for a certain class of
applications which require known interrupt response latencies.

The concept model here is, that you will have all interrupts running in
threads, EXCEPT one or more SA_NODELAY real-time IRQs. Those RT-IRQs may
be required to track satellites, manage I/O for a QOS or RF protocol
stack, shut down a SAW, or a variety of RT-related services.

The IRQ-disable-removal allows that the RT-IRQ encounters minimal
delay. 

Often, that IRQ will also wake up a process, and that process may have
some response-time constraints on it, as well.

SO that's one model that is helped by this design.






-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/