Re: [RFC PATCH 6/7] perf, x86: large PEBS interrupt threshold

[Stephane Eranian]

On Wed, May 28, 2014 at 4:58 PM, Andi Kleen <ak@xxxxxxxxxxxxxxx> wrote:
>> In particular, the 0x90 offset (IA32_PERF_GLOBAL_STATUS). Intel once
>> confirmed to me that that is a direct copy of the similarly named MSR at
>> the time of the PEBS assist.
>
> That is correct.
>
>>
>> This is a problem, since if multiple counters overflow multiple bits
>> will be set and its (afaict) ambiguous which event is for which counter.
>
> When a PEBS counter overflows it clears its respective GLOBAL_STATUS bit
> automatically. You may see multiple STATUS bits in the PEBS record
> if two PEBS counters overflow at exactly the same time, but that is no different
> from the threshold==1 case (and relatively rare)
>
> So the threshold > 1 and the threshold == 1 case work identically.
>
That's what I was trying to get to in my msg.
And I think today, you will generate up to 4 SAMPLE records if all
PEBS event overflowed at the same time and this is fine based on
what I see in intel_pmu_drain_pebs_nhm().

The only part I don't quite follow here is this:
                      if (__test_and_set_bit(bit, (unsigned long *)&status))
                                continue;

Which seems to indicate the code is making sure each counter is
processed only once. But it can only be processed once, if you have
only one record. And if you have multiple, you want to be able to
handle the same counter multiple times, at least once perf PEBS
record. So I am a bit confused about this test.

>> So until you can give an official Intel answer on how all this demuxing
>> is supposed to work and be correct this patch set isn't moving anywhere.
>
> FWIW a patch signed off by intel.com is an official Intel statement.
>
>>
>> > To supply a TID it
>> > requires flushing on context switch. It can however supply the IP
>>
>> On SNB+, previous to SNB it would need to have precise==1. I've seen no
>> such logic in. Instead you seem to artificially limit it to SNB+, for no
>> apparent reason to me.
>
> Only tested on Sandy Bridge+
>
> -Andi
>
> --
> ak@xxxxxxxxxxxxxxx -- Speaking for myself only
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/