Re: [PATCH] local_irq_disable removal

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux