Messages in this thread | | | Subject | Re: [V3][PATCH 0/6] x86, nmi: new NMI handling routines | From | Peter Zijlstra <> | Date | Fri, 26 Aug 2011 16:51:14 +0200 |
| |
On Fri, 2011-08-26 at 10:39 -0400, Don Zickus wrote: > On Fri, Aug 26, 2011 at 11:44:57AM +0200, Peter Zijlstra wrote: > > On Thu, 2011-08-25 at 12:45 -0400, Don Zickus wrote: > > > I spent some time hacking and came up with this patch. I tested it on my > > > core2quad machine trying to enable all the NMI handler I could, mainly > > > perf and kgdb (and oprofile too when perf was disabled). Everything seems > > > to work correctly. If people are ok with this approach, I'll try and test > > > this on more machines. > > > > Right, code looks OK, the only worry that remains is overhead, always > > running all handlers must cost.. > > Yeah nothing is free. My only counter argument is I removed the case > statements in the handlers, so it speeds things up a tiny bit. Also most > machines only seem to have perf and the arch_backtrace handler registered, > with modern intel boxes probably registering the ghes handler too. > > There really isn't much there, at least currently. I would break up the > handler more if I knew a quicker way to distinguish between something like > a self-IPI NMI vs. an on-chip NMI like perf. Then again those NMIs > probably aren't latched differently unlike the external one sitting in the > IOAPIC(??).
Yeah, no clue really.. I still need to read up on those hardware specs (scarce as they are).
As it stands I think we don't have much choice in this and your proposed solution is pretty much it, I mean we have a shared edge interrupt and no sane way to tell who all triggered stuff.
Short of locking all the hardware dudes in a room and not letting them out until they fix that is ;-)
Anyway, aside from 6/6 which wants more comments (personally I think I like you /proc/nmis suggestion best, leaving the single NMI line in /proc/interrupts) I'm fine with these patches.
Thomas any opinions?
| |