Re: [PATCH] local_irq_disable removal

[Thomas Gleixner]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/