Messages in this thread | | | Date | Sun, 27 Apr 1997 07:52:19 -0400 | From | "Theodore Y. Ts'o" <> | Subject | Re: Patches to speed up SLIP and PPP |
| |
Date: Sat, 26 Apr 1997 23:02:47 +0200 (MET DST) From: Ingo Molnar <mingo@pc5829.hil.siemens.at>
[ 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
| |