Messages in this thread | | | Date | Wed, 7 May 2014 17:38:54 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH 1/5] x86, nmi: Add new nmi type 'external' |
| |
* Don Zickus <dzickus@redhat.com> wrote:
> I noticed when debugging a perf problem on a machine with GHES enabled, > perf seemed slow. I then realized that the GHES NMI routine was taking > a global lock all the time to inspect the hardware. This contended > with all the local perf counters which did not need a lock. So each cpu > accidentally was synchronizing with itself when using perf. > > This is because the way the nmi handler works. It executes all the handlers > registered to a particular subtype (to deal with nmi sharing). As a result > the GHES handler was executed on every PMI. > > Fix this by creating a new nmi type called NMI_EXT, which is used by > handlers that need to probe external hardware and require a global lock > to do so. > > Now the main NMI handler can check the internal NMI handlers first and > then the external ones if nothing is found. > > This makes perf a little faster again on those machines with GHES enabled.
So what happens if GHES asserts an NMI at the same time a PMI triggers?
If the perf PMI executes and indicates that it has handled something, we don't execute the GHES handler, right? Will the GHES re-trigger the NMI after we return?
Thanks,
Ingo
| |