Note:  I'm not a kernel hacker, so pardon my gibberish below!

  On the i386, and several other platforms, CLKF_INTR() is
#defined to be (0), which means that no ticks will ever be
charged to `interrupt' (kern_clock.c, around line 969), which
would be viewable via top, and will be via xosview in the
upcoming 1.7.2/1.8.0.  :)

  Some archs (arm32) and FreeBSD use a counter
(current_intr_depth for arm32, intr_nesting_level for FreeBSD)
that is incremented at each interrupt, and decremented when
leaving.  That way, if the profiling timer interrupts during
handling of an interrupt, current_intr_depth is 2 (or higher),
and p->p_iticks and cp_time[CP_INTR] are incremented.

  Could this same technique be used for the remaining ports?
The arm32 code has a comment about being careful before handling
ast stuff, so there are issues about placing the decr at the
right spot.  At this point, I'm over my head, kernel-wise.  But I
added the variable to the i386 locore.s, inc'd it in vector.s,
and dec'd it in icu.s, and checked for it >=2 in kern_clock.c,
and changed CLKF_INTR in cpu.h, and top started showing around
1% being charged for interrupts (I set my HZ to 10000 to force
it to be nonzero even when idle!).  It jumps up to over 70% when
doing 3.5MB/sec IDE PIO.

  I'm sure port-master types or other gurus would be able in
five minutes or less to either make the changes, or say why
they can't be done without much heartache.  :)  But I think
it'd be a nice little mini-feature to throw in for 1.4.

  vmstat currently folds intr+sys together, and user+nice
together, so it won't need to be changed, and other utilities
(top, xosview) should just start seeing a nonzero INTR field, and
DTRT, without even a recompile.

  Brian Grayson