Messages in this thread | | | Date | Thu, 2 Sep 2010 18:18:49 +0200 | Subject | Re: [PATCH 4/4] [x86] perf: fix accidentally ack'ing a second event on intel perf counter | From | Stephane Eranian <> |
| |
On Thu, Sep 2, 2010 at 5:47 PM, Don Zickus <dzickus@redhat.com> wrote: > On Thu, Sep 02, 2010 at 04:39:02PM +0200, Stephane Eranian wrote: >> Don, >> >> On Thu, Sep 2, 2010 at 4:19 PM, Don Zickus <dzickus@redhat.com> wrote: >> > On Thu, Sep 02, 2010 at 10:13:19AM +0200, Stephane Eranian wrote: >> >> Robert, >> >> >> >> Do you have the test program you used to test this? >> >> I believe the NHM hack does not solve the problem, it >> >> just makes it harder to appear. >> > >> > Could be. >> > >> >> >> >> I suspect the real issue is that the GLOBAL_STATUS >> >> bitmask cannot be trusted. I'd like to verify this. >> >> >> >> Has the problem appear only on Nehalem or also on >> >> Westmere? >> > >> > I was able to duplicate on >> > >> > Intel(R) Core(TM) i5 CPU 650 @ 3.20GHz >> > Intel(R) Xeon(R) CPU X5560 @ 2.80GHz >> > >> I managed to reproduce on core i7 860 (without patch4). >> Looking at the code again, I am dubious you ever execute >> the retry goto. If the PMU is disabled and you've just >> cleared the OVF_STAT, then I don't see where the new >> overflows would come from. But that's a separate problem. > > I agree with you, but a printk before the goto proved otherwise! :-) >
Well, I was wrong about my status validation. I had my test wrong. I am seeing discrepancies between OVF_STATUS (status) and manual inspection of each counter (status2) compared to active_mask (act):
[ 489.338564] CPU2 status=0x6 status2=0x4 act=0x7 [ 501.484235] CPU2 status=0x6 status2=0x4 act=0x7 [ 541.686414] CPU2 status=0x6 status2=0x4 act=0x7 [ 561.819575] CPU2 status=0x6 status2=0x4 act=0x7
Note that I have the NMI watchdog on, and running perf record with 2 events only.
OVF_STATUS reports more than what has actually occurred. I think that is fine because in the loop there is a check for against active_mask. Nevertheless, I think there is a problem right there.
I am trying to narrow down when it happens. It seems to occur only when I start a new perf record session. And possibly when perf runs on a CPU that is not monitored:
taskset -c 4 perf record -e cycles -e instructions -F 2000 -a -C 2 -o /dev/null -- sleep 600
> And a printk of the status bit that triggered the goto happened to be the > same one that we initially cleared. Like I said when I initially posted > the patch, I am not sure why it works but it does do something to stem the > NMI.
Yes, I suspect the clearing does not work well. Let's try to do it multiple times in a loop.
> > There is probably a deeper problem here, I was just trying to get the > external/unknown nmis working again. > I suspect that if we were not to use OVF_STATUS, then we would not need the back-to-back nmi logic. NMi cannot be nested. So just looking at the counters should be reliable (excl. PEBS for now).
> Cheers, > Don > -- 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/
| |