Messages in this thread | | | Date | Thu, 24 Apr 2008 06:53:53 -0400 | From | Jeff Garzik <> | Subject | Re: [git patch] free_irq() fixes |
| |
Eric W. Biederman wrote: > I haven't looked at what Jeff's patches in particular so I can not > comment there. I do remember looking at the drivers in question and > yes there were indeed bugs with the handful of drivers that used > the irq parameter. So fixing and cleaning up those drivers so they > use the same idioms as the rest of the kernel should be a maintenance > win. Even if we do keep the irq parameter to the interrupt handler. > > I can comment on where there seems to be a real need for change. > The hard coded NR_IRQS parameter and the arrays of size NR_IRQS are a > kernel scaling bottle neck. They prevents us from building one kernel > that works well on a large ranges of machines sizes. Having a single > array prevents us from allocating the irq structures with NUMA > affinity which slows down irq processing. Having a small number for > NR_IRQS to keep the table compact keeps the irq number from being > readable/useful in the case of MSI and occasionally in the case of > IO_APICs.
Honestly, one thing I was thinking was perhaps a change from
irqreturn_t foo_handler(int irq, void *dev_id) to irqreturn_t foo_handler(struct irq_info *ii, void *dev_id)
which would IMO make the first parameter useful again, by enabling passing of information like MSI message info, or more flexible platform-specific irq info that a platform driver may want. Or direct access to irq_desc or irq_chip info.
Jeff
| |