Re: [RFC 2/2] serial/8250.c: Use self-adjusting list for port poll order.

[Theodore Tso <tytso@mit.edu>]

On Sun, Nov 16, 2008 at 10:23:52AM -0500, George Spelvin wrote:
> The goal is not fewer dropped characters (although there could be a small
> benefit in that direction), and it doesn't improve worst-case timing;
> the goal is to reduce the time spent in the interrupt handler _on average_
> and thereby make more CPU available for other work.

Have you actually measured how much CPU is currently being burned by
the interrupt handler?  And does it actually make a difference with
your optimization?  I did a lot of measurements of this back in the
day of the 40 MHz 386 and 16 serial ports running at 115kbps.  CPU's
have gotten *so* much faster, and as you have pointed the out, the PCI
bus accesses are also faster (and on the ISA bus, given edge-triggered
interrupts, you have to scan all of the ports any way) --- so it's not
obvious to me that it's actually worth it.

There were programs to measure CPU overhead; they normally worked by
doing a certain amount of work (i.e., seeing how many interations of
some mathematical calculation) in a given amount of clock time both
with and without the serial ports being busy.  It might be worthwhile
to see whether for your workload how measurrable the CPU reduction
really is, given modern hardware.  I'm not convinced given the number
of Moore's law doublings since 1992, that it's really going to be
worth it for a rational number of serial ports being serviced by a
modern Linux machine.

						- Ted