Here some numbers from a 166Mhz P5 noMMX.
Aug 18 20:44:33 ark kernel: Linux Interrupt Latency benchmark - Copyright
(C) 1998 Andrea Arcangeli
Aug 18 20:44:33 ark kernel: irqN 1 latency: 726
Aug 18 20:44:33 ark kernel: irqN 2 latency: 1089
Aug 18 20:44:33 ark kernel: irqN 3 latency: 892
Aug 18 20:44:33 ark kernel: irqN 4 latency: 1084
Aug 18 20:44:33 ark kernel: irqN 5 latency: 1064
Aug 18 20:44:33 ark kernel: irqN 6 latency: 759
Aug 18 20:44:33 ark kernel: irqN 7 latency: 1064
Aug 18 20:44:33 ark kernel: irqN 8 latency: 1034
Aug 18 20:44:33 ark kernel: irqN 9 latency: 1034
Aug 18 20:44:33 ark kernel: irqN 10 latency: 1064
Aug 18 20:44:33 ark kernel: latency cycles: mean 979, max 1089, min 726
The latency is measured in CPU tick.
This is the output of `insmod ./lil.o irq=3 num=10 verbose=1`.
I am monitoring the output of the insmod in realtime via network (rsh ark
cat /dev/xconsole) so after every interrupt Linux has to run the network
and the CPU put the lil code out of L1 cache.
If I run without verbose lil code remains in L1 cache and the latency
decrease a lot!
root@ark:/home/andrea# insmod ./lil.o irq=3 num=1000 verbose=0
Aug 18 20:54:45 ark kernel: Linux Interrupt Latency benchmark - Copyright
(C) 1998 Andrea Arcangeli
Aug 18 20:54:45 ark kernel: latency cycles: mean 421, max 1144, min 421
If I remove the schedule() after every interrupt also with verbose = 1 the
latency is reduced at 421 tick.
Conclusion:
With the machine in idle the latency is 421 cycles -> 2.5uSec, with the
machine loaded (so the lil code is kicked out of L1 cache) the latency is
of ~1000 cycles -> 6uSec _as_worse_. This in a "old" P5 noMMX 166Mhz
running 2.1.115.
Andrea[s] Arcangeli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html