Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 1 Oct 2009 10:02:57 +1000 (EST)
From:      Bruce Evans <brde@optusnet.com.au>
To:        John Baldwin <jhb@freebsd.org>
Cc:        arch@freebsd.org
Subject:   Re: Interrupt Descriptions
Message-ID:  <20091001090218.L21015@delplex.bde.org>
In-Reply-To: <200909301732.20589.jhb@freebsd.org>
References:  <200909301732.20589.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 30 Sep 2009, John Baldwin wrote:

> A few folks have asked recently for the ability to add descriptive strings to
> registered interrupt handlers.  This is especially true since the advent of
> MSI with multiple interrupts per device.  I hacked up a prototype today that

Interrupt names should be no longer than 4 (5 works sometimes) characters so
that they can be displayed by systat -v.

>...
>> vmstat -i
> interrupt                          total       rate
> irq1: atkbd0                           8          0

The 4-5 characters doesn't include "irqN".  (systat -v already does extra
work to avoid the bad naming scheme visible here.  It moves the "irqN" to
the end, and removes the ":", else truncating these names would give a
larger mess and there would only be space for 3-4 characters of the device
name after wasting 1 for the ":".)

"atkbd0" is already far too long, so systat -v would display "atkbd0 irq"
in the 10 columns available, except it omits "irq" in this case so
as to print the interrupt number, and actually displays "atkbd0 1".

> irq4: uart0                          751          5
> irq6: fdc0                             6          0
> irq14: ata0                           36          0
> irq20: uhci0                          20          0

These are short enough to be displayed by systat -v (after removal of the
":" in 2 cases and after removal of the ":" and the "irq" in 1 case).

> irq23: uhci3 ehci0                     2          0

systat -v has no chance of displaying multiple devices per interrupt.  I
think it finds no space to print even the irq number, and also loses
the ehci number after truncating at "uhci3 ehci".

> irq28: mpt0                         1661         11

Short enough.

> irq256: igb0:tx 0                    880          6

I think this gets truncated to "igb0:tx 0 ".  The device name doesn't
follows the rules for naming devices (should contain no whitespace), so
the final "0" looks like the interrupt number.

Interrupt numbers > 99 cause further problems for systat.  Now there
is only space for 3 characters in the device name ("xx0 irq256" takes
10 columns).

> irq257: igb0:rx 0                   1098          7
> irq258: igb0:link                      3          0
> irq259: igb1:tx 0                      1          0
> irq260: igb1:rx 0                    134          0
> irq261: igb1:link                      3          0

Similar messes.

systat has no support for varying the terminal width, and adding such
support would be difficult because the display is very complicated and
hard-coded, so the truncation occurs even if you have a wide terminal.
Adding support for the English parser needed to translate more cases would
be even more difficult.  The "irqN:" translation is MD (probably only
helps for amd64 and i386).

The above output shows related misformatting for vmstat.  Interrupt
name strings are supposed to be NUL-terminated and packed into a string
space, mainly to match the historical interface to vmstat, which was
designed mainly for space-efficiency.  I think they are still in a
string space, but at least on amd64 and i386 the implementation is
extremely space-inefficient, with many unused entries and every entry
padded with spaces to length MAXCOMLEN bytes (plus the NUL terminator).
MAXCOMLEN is 19, and most of the 19 are used for the verbose names in
the above.  Then vmstat leaves about 15 more spaces before the totals
column (it uses format "%-*s %20llu..."), giving the above ugly output.
The "*" in the format is supposed to be dynamic, but this is defeated
by the space-padding.  Leaving space for 20-digit numbers is bogus:
the 20 is a hard coding of the number of digits needed to display the
largest 64-bit long long, but long longs might be longer than that,
and the maximum is unreachable even with 64-bit long longs.

OTOH, MAXCOMLEN is a bit short for a description.

Bruce



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091001090218.L21015>