Re: Why no interrupt priorities?

[Mark Gross <mgross@linux.co.intel.com>]

On Thursday 26 February 2004 13:30, Arjan van de Ven wrote:
> 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.

Keep in mind the context is Linux running on non-sane hardware, sloooow CPUs, 
latency sensitive small io buffers etc. Losing system wide throughput to have 
the hardware codec not be starved is a happy trade off to make.

So far all the comments are very PC centric. I suspect the history of the no 
interrupt priorities goes back a lot of years.  Perhaps the answer is that it 
never seemed to help having priorities much on PC hardware so lets not deal 
with the complexity in the software.

Any more historical insights?
I wonder how hard it would be add for embedded types of 
applications/architectures?

--mgross

>
> 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....