Re: Interrupt routine usage not shown by top in 8.0

From: Scott Long <scottl_at_samsco.org>
Date: Thu, 12 Mar 2009 17:42:27 -0600
Barney Cordoba wrote:
> I'm fireing 400Kpps at a udp blackhole port. I'm getting 6000 interrupts
> per second on em3:
> 
> testbox# vmstat -i; sleep 1; vmstat -i
> interrupt                          total       rate
> irq1: atkbd0                           1          0
> irq6: fdc0                             1          0
> irq17: uhci1+                       2226          9
> irq18: uhci2 ehci+                     9          0
> cpu0: timer                       470507       1993
> irq256: em0                          665          2
> irq259: em3                      1027684       4354
> cpu1: timer                       470272       1992
> cpu3: timer                       470273       1992
> cpu2: timer                       470273       1992
> Total                            2911911      12338
> 
> interrupt                          total       rate
> irq1: atkbd0                           1          0
> irq6: fdc0                             1          0
> irq17: uhci1+                       2226          9
> irq18: uhci2 ehci+                     9          0
> cpu0: timer                       472513       1993
> irq256: em0                          668          2
> irq259: em3                      1033703       4361
> cpu1: timer                       472278       1992
> cpu3: timer                       472279       1992
> cpu2: timer                       472279       1992
> Total                            2925957      12345
> 
> 
> top -SH shows:
> 
>   PID  STATE  C   TIME    CPU COMMAND
>    10  CPU3   3   7:32 100.00% idle
>    10  CPU2   2   7:32 100.00% idle
>    10  RUN    0   7:31 100.00% idle
>    10  CPU1   1   7:31 100.00% idle
> 
> This implies that CPU usage is substantially under-reported in general
> by the system. Note that I've modified em_irq_fast() to call 
> em_handle_rxtx() directly rather than scheduling a task to illustrate
> the problem
> 

With unmodified code, what do you see?  Are you sending valid UDP frames 
with valid checksums and a valid port, or is everything that you're 
blasting at the interface getting dropped right away?  Calling 
em_handle_rxtx() directly will cause a very quick panic once you start
handling real traffic and you encounter a lock.

Scott
Received on Thu Mar 12 2009 - 23:07:26 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:43 UTC