![]() | |||||||||||||
Messages in this thread |
On Thu, 26 Feb 2004 17:36:34 -0800 "Grover, Andrew" <andrew.grover@intel.com> wrote: | > On Thursday 26 February 2004 13:30, Arjan van de Ven wrote: | > > 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. | | Is the assumption that hardirq handlers are superfast also the reason | why Linux calls all handlers on a shared interrupt, even if the first | handler reports it was for its device? Somehow I don't think that's the reasoning. Is there a safe method to determine that there are no other pending interrupts on one shared interrupt? i.e., that other devices don't also have interrupts pending? -- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2005-03-22 13:01 [from the cache] ©2003-2008 | |||||||||||||