Re: bisected: 'perf top' causing soft lockups under Xen

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Wed, Feb 15, 2012 at 11:17:41AM -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Feb 15, 2012 at 10:25:44AM +0100, Peter Zijlstra wrote:
> > On Wed, 2012-02-15 at 00:57 -0800, Steven Noonan wrote:
> > > It seems to me that there are two options for fixing this, but I'm
> > > probably lacking the necessary context (or experience with Xen). Either:
> > > 
> > > - The patch provided by Ben needs to have additional work to specially
> > >   handle IRQ_WORK_VECTOR, since it seems to be a special case where
> > >   there's no event channel attached for it. Perhaps adding an event
> > >   channel for this is the fix? Seems high-overhead, but I lack a good
> > >   understanding of how interrupts are handled in Xen.
> > 
> > So that's a self-IPI, is Xen failing to implement this?
> 
> It does have self-IPIs.
> > 
> > > or
> > > 
> > > - Perf needs to be "enlightened" about Xen and avoid sending an IPI in
> > >   the first place.
> > 
> > Uhm, no. If anything Xen should simply not implement
> > arch_irq_work_raise(). The callbacks are then ran from the timer
> > interrupt.
> 
> Looks like that wouldn't be too difficult - meaning implement a similar
> form of IRQ_WORKER that would call
> 
>  inc_irq_stat(apic_irq_work_irqs);
>  irq_work_run();
> 
> .. along with the rest of the stuff from Ben's patch. Let me see if I can
> prep a patch.

Peter,

I am going to start cracking at this to see why the self-IPI don't seem to
work, while the patch that was removed (so the NMI, would just check on its
own CPU whether it was called without doing the NMI).

But in the meantime, are there any good docs to look over to get a good idea
of how the perf code works?

Thanks.