Prev: mtd: Extend physmap_of to let the device tree specify the parition probe
Next: [RELEASE] LTTng 0.210 for kernel 2.6.33.2
From: Mathieu Desnoyers on 12 Apr 2010 20:30 * Anton Blanchard (anton(a)samba.org) wrote: > > Hi, > > > states that this is done for setups where no in-kernel handler is called. But > > it does not say if tracing the beginning and end of handle_IRQ_event() from > > kernel/irq/handle.c would fix the problem. That would be a lot neater than > > this arch-specific solution. > > Unfortunately that misses this problem completely. On some versions of the > POWER hypervisor we can be presented with interrupts for our virtualisation > layer that get handled in the get_irq hypervisor call. The code looks like > this: > > > void do_IRQ(struct pt_regs *regs) > { > struct pt_regs *old_regs = set_irq_regs(regs); > unsigned int irq; > > trace_irq_entry(regs); > > irq_enter(); > > check_stack_overflow(); > > irq = ppc_md.get_irq(); <------------- jitter spikes here > > if (irq != NO_IRQ && irq != NO_IRQ_IGNORE) > handle_one_irq(irq); > else if (irq != NO_IRQ_IGNORE) > __get_cpu_var(irq_stat).spurious_irqs++; > > > We've had HPC customers who have experienced jitter in their applications > caused by this and as a result I added the events so we can monitor it. > > Since this is a POWER specific issue I'm happy to rename the trace events to > powerpc_irq_entry/exit. We could also look at changing the tracepoints, eg > putting it around the ppc_md.get_irq(), but I can't see how we can remove > them completely. OK, I see. How about arch_irq_entry/exit() ? This way, if we need to do something similar on another arch at the architecture-level, we can use the same names. Thanks, Mathieu > > Anton -- Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS Inc. http://www.efficios.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |