Re: [tip:perf/urgent] perf, x86: Catch spurious interrupts afterdisabling counters

From: Stephane Eranian
Date: Wed Sep 29 2010 - 09:13:38 EST


On Wed, Sep 29, 2010 at 2:54 PM, Robert Richter <robert.richter@xxxxxxx> wrote:
> On 29.09.10 14:53:01, Robert Richter wrote:
>> Stephane,
>>
>> On 29.09.10 08:26:41, Stephane Eranian wrote:
>> > You've applied the fix only to the generic X86 interrupt handler
>> > which is currently used by AMD64 processors.
>>
>> (... and P4).
>>
>> > It seems to me that this "in-flight interrupt after disable" problem
>> > may also happen on Intel and should therefore also be added
>> > to intel_pmu_handle_irq(). Don't you think so?
>>
>> It only happens if the active_mask is used for checking single
>> counters for overflows.
>>
On Intel there is a double-check. You obtain the overflow mask
from HW. For each bit set, you verify it corresponds to an active
event. If not, you ignore:

for_each_set_bit(bit, (unsigned long *)&status, X86_PMC_IDX_MAX) {
struct perf_event *event = cpuc->events[bit];

handled++;

if (!test_bit(bit, cpuc->active_mask))
continue;
}

I think the logic is similar. What makes the difference, it seems, is that
handled is incremented unconditionally if the ovfl_mask says it has
an overflow, i.e., before active_mask is checked.

On Westmere, we've seen situations where the overflow mask and active
mask did not agree.

On counter disable, the overflow mask bit is not cleared, thus one may iterate
in the loop and fail the active_mask. But handled would be incremented in that
case, so that would behave like in your patch.




>> Systems with Intel Architectural Perfmon use the status mask msr to
>> determine which counter overflowed. In intel_pmu_handle_irq() the
>> handled counter is incremented in this case even if the counter is not
>
> I mean handled count (variable 'handled').
>
>> active, so everything should be fine here.
>>
>> -Robert
>>
>> --
>> Advanced Micro Devices, Inc.
>> Operating System Research Center
>
> --
> Advanced Micro Devices, Inc.
> Operating System Research Center
>
>
--
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/