Hi,

quoted text
> 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.

Anton
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/