Re: [PATCH 1/5] x86, nmi: Add new nmi type 'external'

2014-05-09 Thread Don Zickus
On Fri, May 09, 2014 at 09:10:50AM +0200, Ingo Molnar wrote: > > * Don Zickus wrote: > > > On Thu, May 08, 2014 at 07:35:01PM +0200, Ingo Molnar wrote: > > > > > > * Don Zickus wrote: > > > > > > > > > Again, I don't have a solution to juggle between PMI performance > > > > > > and reliable

Re: [PATCH 1/5] x86, nmi: Add new nmi type 'external'

2014-05-09 Thread Ingo Molnar
* Don Zickus wrote: > On Thu, May 08, 2014 at 07:35:01PM +0200, Ingo Molnar wrote: > > > > * Don Zickus wrote: > > > > > > > Again, I don't have a solution to juggle between PMI performance > > > > > and reliable delivery. We could do away with the spinlocks and > > > > > go back to single

Re: [PATCH 1/5] x86, nmi: Add new nmi type 'external'

2014-05-08 Thread Don Zickus
On Thu, May 08, 2014 at 07:35:01PM +0200, Ingo Molnar wrote: > > * Don Zickus wrote: > > > > > Again, I don't have a solution to juggle between PMI performance > > > > and reliable delivery. We could do away with the spinlocks and > > > > go back to single cpu delivery (like it used to be).

Re: [PATCH 1/5] x86, nmi: Add new nmi type 'external'

2014-05-08 Thread Ingo Molnar
* Don Zickus wrote: > > > Again, I don't have a solution to juggle between PMI performance > > > and reliable delivery. We could do away with the spinlocks and > > > go back to single cpu delivery (like it used to be). Then > > > devise a mechanism to switch delivery to another cpu upon >

Re: [PATCH 1/5] x86, nmi: Add new nmi type 'external'

2014-05-08 Thread Don Zickus
On Wed, May 07, 2014 at 06:27:46PM +0200, Ingo Molnar wrote: > > [...] But I guess in theory, if a PMI NMI comes in and before the > > cpu can accept it and GHES NMI comes in, then it would suffice to > > say it may get dropped. That would be not be good. Though the race > > would be very sma

Re: [PATCH 1/5] x86, nmi: Add new nmi type 'external'

2014-05-07 Thread Don Zickus
On Wed, May 07, 2014 at 06:27:46PM +0200, Ingo Molnar wrote: > > * Don Zickus wrote: > > > On Wed, May 07, 2014 at 05:38:54PM +0200, Ingo Molnar wrote: > > > > > > * Don Zickus wrote: > > > > > > > I noticed when debugging a perf problem on a machine with GHES enabled, > > > > perf seemed slo

Re: [PATCH 1/5] x86, nmi: Add new nmi type 'external'

2014-05-07 Thread Ingo Molnar
* Don Zickus wrote: > On Wed, May 07, 2014 at 05:38:54PM +0200, Ingo Molnar wrote: > > > > * Don Zickus 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 al

Re: [PATCH 1/5] x86, nmi: Add new nmi type 'external'

2014-05-07 Thread Don Zickus
On Wed, May 07, 2014 at 05:38:54PM +0200, Ingo Molnar wrote: > > * Don Zickus 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.

Re: [PATCH 1/5] x86, nmi: Add new nmi type 'external'

2014-05-07 Thread Ingo Molnar
* Don Zickus 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 lo

[PATCH 1/5] x86, nmi: Add new nmi type 'external'

2014-05-07 Thread Don Zickus
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 w