Messages in this thread | | | Subject | Re: [PATCH] local_irq_disable removal | From | Sven-Thorsten Dietrich <> | Date | Sat, 11 Jun 2005 17:09:52 -0700 |
| |
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/
| |