Prev: mtd: Extend physmap_of to let the device tree specify the parition probe
Next: [RELEASE] LTTng 0.210 for kernel 184.108.40.206
From: Mathieu Desnoyers on 12 Apr 2010 20:30
* Anton Blanchard (anton(a)samba.org) wrote:
> > 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
> void do_IRQ(struct pt_regs *regs)
> struct pt_regs *old_regs = set_irq_regs(regs);
> unsigned int irq;
> irq = ppc_md.get_irq(); <------------- jitter spikes here
> if (irq != NO_IRQ && irq != NO_IRQ_IGNORE)
> else if (irq != NO_IRQ_IGNORE)
> 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.
Operating System Efficiency R&D Consultant
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/