[Correction] Interrupt coalescing for eepro on 2.2.13.

[Sandeep Sikka]

Just wanted to correctly describe the numbers: We saw about 21% of CPU sytem 
time in handle_IRQ_event and about 4% in speedo_interrupt. speedo_interrupt 
is the only interrupt handler registered on that IRQ.
Calls to speedo_interrupt accounted for almost 98% of the overall interrupts 
raised to the kernel.

Thanks. Sandeep.
------
Hi,

We pulled the latest version (1.09) of eepro100.c and patched it with Linux 
2.2.13. We profiled the kernel and also added some instrumentation to 
measure the number of calls to speedo_interrupt and various other interrupt 
handlers in the kernel.

We found that the CPU was spending about 20% of the time processing 
speedo_interrupt (almost all the interrupt handler calls to the kernel 
finally resolved to speedo_interrupt).

So we are wondering if the interrupt coalescing on the card/driver is 
busted. There were a few emails on this list (last year) claiming that the 
chip did some sophisticated coalescing on the receive side and hardly 
interrupts on transmits (except when the queue is empty). But then we 
shouldn't be seeing so much time spent in processing interrupts.

We don't have access to the programmer's manual from Intel (that requires an 
NDA... bummer!) Has anyone seen similar numbers?  Has anyone profiled for 
coalescing interrupts?

Any information would be much appreciated. I promise to condense all 
feedback on this to the list.

Thanks. Sandeep.

PS: I tried subscribing to the list. Am not sure if I succeeded. Please cc 
me on any replies. Thanks!
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

-------------------------------------------------------------------
To unsubscribe send a message body containing "unsubscribe"
to linux-eepro100-request@beowulf.org