On Wed, Mar 07, 2012 at 02:49:46AM +0000, Ming Lei wrote: > Hi Will, Hello, > On Fri, Jan 27, 2012 at 11:54 PM, Will Deacon <will.deacon@xxxxxxx> wrote: > > Ok. Note that on ARM the PMU generates a standard IRQ (i.e. not an NMI) so > > you may miss samples if they occur during critical kernel sections (and if > > you look at a profile, spin_unlock_irqrestore will be quite high). > > Also looks no any irq handler functions can be observed at a profile even > though they may be run at a very high frequency. > > So could we configure ARM PMU interrupt as FIQ to address the above issues? I thought about that in the past but the problem is finding hardware which allows this. It probably means that you need a second GIC which can route interrupts onto the FIQ line into the CPU. Given that FIQ is usually claimed for secure interrupts, there could also still be latency issues here. A better (read: highly invasive) way to fix this is using interrupt priorities at the distributor. You then have to hack the interrupt disabling code so that it disables interrupts below a certain priority if they occur during an IRQ-off section. The re-enabling code would then have to undo those decisions and allow the interrupts to be serviced. Pretty nasty stuff. Will -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
