On Tue, Aug 26, 2008 at 8:08 PM, Garrett D'Amore <[EMAIL PROTECTED]> wrote: > I'm getting ready to write the kstat intr support for a revised audio > driver, and I noticed that it only reports hard, not spurious > interrupts. That got me thinking. > > On an x86 system at least, the interrupt chain logic keeps retrying the > interrupt until all devices report DDI_INTR_UNCLAIMED. So, a typical > device on an unshared bus will have at least 1 spurious interrupt for > each hard interrupt. (Ignoring the case where successive calls into the > drivers ISR return DDI_INTR_CLAIMED, of course.) > > On a system with shared interrupts (more and more common, *especially* > on x86 systems) the spurious interrupt count is likely to be much higher > for some devices, because a busy device will cause spurious interrupts > (or the appearance thereof) in the less busy device(s) on the same > interrupt. > > The upshot of all this is, it seems to me that drivers cannot reliably > count spurious interrupts. > > The other observation is that very few drivers bother to use > kstat_intr. (Some drivers, such as NIC drivers, report interrupts > differently, such as in a named kstat.) > > There's the intrstat program which uses dtrace, but from what I can > tell, it seems to record entries into the interrupt handler, which > doesn't correctly count hard interrupts (see above for why not!) > > So what I'm thinking is that the interrupt framework itself could count > interrupts and keep track of this in a kstat. This is useful for debug, > but it would also be able to provide a more accurate picture than > intrstat does. (Furthermore, as much as I like dtrace, it might make it > possible to build a portable intrstat, that was able to report not just > PCI interrupts but other kinds of interrupts -- hard, soft, pci, pciex, > isa, usb, firewire, sbus, and maybe other kinds in the future (for > example SDcard can support IO devices that interrupt, although the > framework and nexus drivers I just putback into 97 don't have support > for SDIO yet.) > > The framework could also count spurious interrupts -- a spurious > interrupt being one where the top-level CPU or nexus specific interrupt > handler dispatched, but didn't find *any* handler that could service the > interrupt. (This could be counted as spurious interrupt for *each* > device on the bus, or it could be counted in a separate top-level > spurious interrupt counter for the bus.) > > Thoughts?
Garrett, I think this idea is worth implementing. Consolidation of interrupt accounting into a single place seems like a right thing to do. -- Regards, Cyril _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
