Messages in this thread |  | | | Subject | Re: [PATCH] local_irq_disable removal | | From | Thomas Gleixner <> | | Date | Sun, 12 Jun 2005 02:28:39 +0200 |
| |
On Sat, 2005-06-11 at 17:09 -0700, Sven-Thorsten Dietrich wrote: > 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.
Nobody denied that. I'm just cautious about arguments which count instruction cylces on a given CPU.
> 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.
No problem with that. I have done this already and know about the pro and cons.
As I pointed out before, speed is not always the measure.
The point is configurability of features, but OTH you _cannot_ implement a CONFIG option for each particular spinlock. You have to come down to a certain set of config options by experimentation or by analysing ofcode paths. Lot of work to be done though.
tglx
- 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/
|  |