Re: [PATCH] local_irq_disable removal

Sven-Thorsten Dietrich
2005-06-12T00:11:10Z

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.