[patch 0/8] [RFC PATCH] nmi watchdog: x86 32/64 cleanup

[dzickus <dzickus@redhat.com>]

A major cleanup of the nmi watchdog on the i386 and x86_64 archs.

This little project started out as a way to get unknown_nmi_panic working on
an x86_64 SMP machine. But after Andi rejected my dirty little hack ;), it
grew into a spring cleaning of the nmi watchdog.

The fix Andi wanted led to a conflict with how oprofile worked.  This led to
a reservation layer around the performance counters and a bunch of changes
in oprofile startup.  All the reservation layer consists of is reserving a
bit that corresponds to a performance counter.  The intent here is to
prevent subsystems like oprofile and nmi watchdog from stomping on each
other when trying to manipulate these counters. Currently, oprofile must
stop the nmi watchdog before using the counters.  This approach does not
encourage any sharing. :) 

During the testing of this reservation layer, I ran into more and more bugs
from old hacks (notably in the SMP cases).  As a result I found myself
rewriting a lot of this code.  I think I straightened everything out, except
for enabling/disabling the nmi watchdog on an ioapic.  The
enable_irq/disable_irq macros don't seem to work for me and I don't know
enough about the subsystem to figure it out either. 

Of course the oprofile code is shared with the i386 arch, so all the changes
I did in x86_64 had to be duplicated over there too.

I tested these changes on a Xeon (UP/SMP), P4 (32/64, UP/SMP) and under
various boot-up defaults (nmi-watchdog=0,1,2).  I also worked on some of
these changes with Andi Kleen and the oprofile folks, so these ideas
shouldn't be too surprising, just perhaps the implementation. :o

Any thoughts/feedback/criticism to clean this up more and probably fix some of my
coding style would be appreciated.

Cheers,
Don

--
-
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/