[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTins3MqKvrs94KYCSyMqcoo-Lr0MsfZM1Ew5VOzQ@mail.gmail.com>
Date: Fri, 10 Sep 2010 14:13:28 +0200
From: Stephane Eranian <eranian@...gle.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Don Zickus <dzickus@...hat.com>, mingo@...e.hu,
robert.richter@....com, gorcunov@...il.com, fweisbec@...il.com,
linux-kernel@...r.kernel.org, ying.huang@...el.com,
ming.m.lin@...el.com, yinghai@...nel.org, andi@...stfloor.org
Subject: Re: [PATCH 0/3 v2] nmi perf fixes
I think the broader issue here is that I think we should not have
so many subsystems hanging off of that die_register(). The NMI
should be for perf_events only. Many in there have nothing to do
with performance monitoring. They are mostly debug features.
On Fri, Sep 10, 2010 at 2:10 PM, Stephane Eranian <eranian@...gle.com> wrote:
> On Fri, Sep 10, 2010 at 1:41 PM, Peter Zijlstra <peterz@...radead.org> wrote:
>> On Thu, 2010-09-02 at 15:07 -0400, Don Zickus wrote:
>>> Fixes to allow unknown nmis to pass through the perf nmi handler instead
>>> of being swallowed. Contains patches that are already in Ingo's tree. Added
>>> here for completeness. Based on ingo/tip
>>>
>>> Tested on intel/amd
>>>
>>> v2: patch cleanups and consolidation, no code changes
>>>
>>> Don Zickus (1):
>>> perf, x86: Fix accidentally ack'ing a second event on intel perf
>>> counter
>>>
>>> Peter Zijlstra (1):
>>> perf, x86: Fix handle_irq return values
>>>
>>> Robert Richter (1):
>>> perf, x86: Try to handle unknown nmis with an enabled PMU
>>>
>>> arch/x86/kernel/cpu/perf_event.c | 59 +++++++++++++++++++++++++-------
>>> arch/x86/kernel/cpu/perf_event_intel.c | 15 +++++---
>>> arch/x86/kernel/cpu/perf_event_p4.c | 2 +-
>>> 3 files changed, 56 insertions(+), 20 deletions(-)
>>
>> Both Ingo and I are getting Dazed and confused on our AMD machines, it
>> started before yesterday (that is, after backing out all my recent
>> changes it still gets dazed), so I suspect this set.
>>
>> I'll look at getting a trace of the thing, but if any of you has a
>> bright idea...
>
> I still don't buy the back-to-back NMI thing. I suspect there is
> something else going on. I have continued to track it down.
> I got closer yesterday, until I ran into other issues. It may
> have to do with throttling. I am still trying to understanding
> why the OVF_STATUS does not match the check based on
> the counter values.
>
>>
>
--
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