Date:	Fri, 1 Oct 2010 13:53:37 +0200
From:	Stephane Eranian <eranian@...gle.com>
To:	Robert Richter <robert.richter@....com>
Cc:	Don Zickus <dzickus@...hat.com>,
	Cyrill Gorcunov <gorcunov@...il.com>,
	"mingo@...hat.com" <mingo@...hat.com>,
	"hpa@...or.com" <hpa@...or.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"yinghai@...nel.org" <yinghai@...nel.org>,
	"andi@...stfloor.org" <andi@...stfloor.org>,
	"peterz@...radead.org" <peterz@...radead.org>,
	"ying.huang@...el.com" <ying.huang@...el.com>,
	"fweisbec@...il.com" <fweisbec@...il.com>,
	"ming.m.lin@...el.com" <ming.m.lin@...el.com>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"mingo@...e.hu" <mingo@...e.hu>
Subject: Re: [tip:perf/urgent] perf, x86: Catch spurious interrupts after
 disabling counters

[repost due to mime-encoding error on my part]

On Fri, Oct 1, 2010 at 9:17 AM, Robert Richter <robert.richter@....com>wrote:

> On 30.09.10 15:44:51, Don Zickus wrote:
> > On Thu, Sep 30, 2010 at 11:12:46AM +0200, Robert Richter wrote:
>
> > > As soon as you stop executing the chain, there are chances to miss an
> > > nmi for other parts of the system. Where is no way to avoid this. So
> > > your argument above is valid also for regular perf nmis and not only
> > > for catched-spurious or back-to-back nmis.
> >
> > I don't agree with that.  Most nmi handlers can do a check to see if
> their
> > subsystem triggered an nmi or not.  Now we may not catch it in the right
> > order because one handler is higher in the chain than the other, but
> > ultimately the other handler will get its chance to execute because it
> > fired its own nmi (which hasn't been lost).
>
> No, as soon as a handler with higher priority detected an nmi by its
> own and handled it, it returns with a stop and all subsequent handlers
> get ignored without the chance to check their hardware. So, if perf
> consumes an nmi because a counter triggered, there are rare cases that
> other handlers may not be executed.
>

And that's what you want to avoid.

> > Whereas the problem Stephane is describing is that the heurestics of the
> > perf counters 'eats' an NMI, thus possibly starving another handler.
> > With back-to-back nmis we are at least polite, letting everyone have a chance
> > to process the nmi before we indulge ourselves and 'eat' it (if it still
> > around to be eaten).
> >
> > However in the case of the 'catched-spurious', we selfishly 'eat' the NMI
> > without really knowing if it was our to be eaten.  That was the
> > difference and the concern.
>
> But, this argument is valid. It would be better to handle
> catched-spurious in the 'unknown' path to give other handlers the
> chance to check their hardware.
>

Yes, that was my point. You cannot do it until the kernel invokes the
handler on the 'unknown nmi' callchain.


> I don't think this is a show-stopper for v2.6.36 even because the perf
> handler runs with the lowest priority now. So we will have enough time
> after the merge window to improve the code here.
>
>
That's another issue I have with this NMI callchain logic. It is hard to tell
who's in front of who in each callchain. You may have two registered users
at the same priority, the one which registers last gets priority.

We may not want perf_event to run at the lowest priority because it is
performance sensitive, remember that the counters are running until
you get to the handler. Unlike many of the other subsystems on the
call chain perf_event is doing performance monitoring not debugging.
The rate of calls on the chain is now very high.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists