[ trace was done on a 100 MHz Pentium, the interrupt happened in a quite
cache-cold situation, thats why numbers are 50% higher than one would
expect ]
Summary of latencies:
"slow" irq entry part ------------- 0.37 usecs
"slow" irq exit part -------------- 0.76 usecs
"slow" irq resched decision part -- 0.41 usecs
The summary latency of all the "slow" part is 1.54 usecs. Total summary of
the interrupt-generated latencies: 59.10 usecs. The "slow" part isnt slow
at all.
A bit of history here. The fast interrupts were originally done as part
of my project to see if I could make a 40 MHz 386 with a 16450 could
handle a loop-ed back 115kbaud serial connection. That's at least
11,520 interrupts a second!
When you multiply 11520 * 1.54 usecs, you find that on a Pentium 100,
17.7% of your CPU time is spent in the interrupt system's overhead.
(This doesn't yet count the time spent in rs_interrupt(), where the
*real* device servicing has to happen). I will leave it to your own
exercise of imagination what happens on a 40MHz 386. :-)
I suspect that Linus is right, though, that by optimizing the interrupt
return path so that it is separate from the system call return path will
be a win. While people may think that it's unreasonable to expect a 386
with 16450's could handle 115200 connections, Linux could do it! (When
much of the competition couldn't. :-) And even today, there are people
who are using 16+ serial ports using dumb serial cards, which again is
probably only possible because the interrupt overhead had been optimized
down to a very low level.
The bottom line is that you can't just say that 1.54 usecs is a small
amount of overhead, because in the serial driver, you get a lot of
interrupts. Although it might not be obvious, the interrupt routines
*are* part of a tight loop. :-)
- Ted