Messages in this thread | | | Date | Sun, 16 Nov 2008 11:49:54 -0500 | From | Theodore Tso <> | Subject | Re: [RFC 2/2] serial/8250.c: Use self-adjusting list for port poll order. |
| |
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
| |