Re: Why no interrupt priorities?

[Arjan van de Ven <arjanv@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1494 bytes --]

On Thu, 2004-02-26 at 22:02, Tim Bird wrote:
> Richard B. Johnson wrote:
> > On Thu, 26 Feb 2004, Tim Bird wrote:
> > 
> >>What's the rationale for not supporting interrupt priorities
> >>in the kernel?
> > 
> > Interrupt priorities are supported and have been supported
> > since the first cascaded interrupt controllers and, now
> > with the APIC. 
> 
> Please forgive my ignorance.  I'm not sure what's going
> on with 2.6 and work queues, but do the hardware priorities
> allow you to control scheduling of interrupt bottom halves?


hardware IRQ priorities are useless for the linux model. In linux, the
hardirq runs *very* briefly and then lets the softirq context do the
longer taking work. hardware irq priorities then don't matter really
because the hardirq's are hardly ever interrupted really, and when they
are they cause a performance *loss* due to cache trashing. The latency
added by waiting briefly is going to be really really short for any sane
hardware.

Now doing priorities in softirq context... well... here again it's a
case of a tiny latency hit vs a lot of cache trashing. If your softirq
handler runs in 10 cachemisses (it's useless to talk about cpu cycles
since most of teh time you'll be cache bound) that's not too long
latency, but if you interrupt it it might get 15 or more cachemisses
instead. That again will increase the delay the user context gets from
irq's.... so from a userspace pov you actually increased irq latency....

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]