On Sat, Oct 2, 2010 at 11:35 AM, Robert Richter <robert.richter@amd.com> wrote:
quoted text
> On 01.10.10 07:53:37, Stephane Eranian wrote:
>
>> 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.
>
> Yes, actually the perf handler should run with the highest priority to
> reduce overhead when executing the handler chain. As this will cause
> implications to other handlers I think the most promising approach
> will be Andi's suggestion to separate the nmi handlers from the die
> chain by adding a new one. We should consider this when reworking the
> die handler (cc'ing Huang).
>
I haven't seen Andi's suggestion. But I am guessing he is suggesting
adding a new chain that would be called first and where there would
ONLY be the perf_event subsystem. To handle the spurious PMU
interrupts perf_events would also be added to the lowest priority
list (the one called last) and it would be placed as the last item on
that list (equiv to NMI_UNKNOWN).

Is that the idea?
--
unsubscribe notice
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/