On Mon, 2012-09-10 at 10:02 -0400, Steven Rostedt wrote: > I agree too. I'm a bit concerned about the lack of coverage the > irq_enter() and irq_exit() have in the timer interrupt: > > may_hard_irq_enable(); > > trace_timer_interrupt_entry(regs); > > __get_cpu_var(irq_stat).timer_irqs++; > > #if defined(CONFIG_PPC32) && defined(CONFIG_PMAC) > if (atomic_read(&ppc_n_lost_interrupts) != 0) > do_IRQ(regs); > #endif > > old_regs = set_irq_regs(regs); > irq_enter(); > > > I'm guessing that call to do_IRQ() has to do with lazy irq handling?
Not exactly. may_hard_irq_enable() does, it will hard-enable interrupts (while keeping them soft-disabled) if there isn't a recorded "level" interrupt pending already (in which case it's pointless, we'll just be interrupted again and re-disable). The do_IRQ() hack is an old hack for ancient 32-bit powermacs who could lose interrupts, it's a sideband mechanism we have to re-emit them, which nowadays could probably be replaced with something more modern, it's just that nobody ever wants to touch that code. > Anyway, there may be a reason to have the tracepoint before this call, > but I'm not sure it really is that important. It should probably be best > to move it after the irq_enter(). There's side-effects with calling > things from interrupt context outside of irq_enter/exit(). Cheers, Ben. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
