lkml.org 
[lkml]   [2004]   [Feb]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: Why no interrupt priorities?
    From
    Date
    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....
    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2005-03-22 14:01    [W:0.022 / U:0.148 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site