[POLLING] strange interrupt/system load

[Barney Cordoba]

--- On Sat, 9/12/09, rihad <rihad at mail.ru> wrote:

> From: rihad <rihad at mail.ru>
> Subject: [POLLING] strange interrupt/system load
> To: freebsd-net at freebsd.org
> Date: Saturday, September 12, 2009, 3:27 AM
> The box experiences ~230 mbit/s
> traffic flow through it. I've doubled some sysctls after
> reading polling(4):
> kern.polling.each_burst=10 # was: 5
> kern.polling.burst_max=350 # was: 150
> 
> FreeBSD 7.2-RELEASE-p3 amd64
> HZ=1000
> 
> Now for the fun part.
> 
> With kern.polling.idle_poll = 1 top shows:
> CPU:  0.0% user,  0.0% nice, 26.9% system, 
> 3.1% interrupt, 70.0% idle
> ~8000 interrupts/s total according to systat -vmstat:
> 1999 cpu0: time
> 2000 cpu1: time
> 1999 cpu2: time
> 1999 cpu3: time
> 
> With kern.polling.idle_poll = 0 top shows:
> CPU:  0.0% user,  0.0% nice,  0.0% system,
> 13.9% interrupt, 86.0% idle
> Still the same ~8000 clock interrupts/s.
> 
> Under both scenarios polling is enabled on both em0 and em1
> through ifconfig.
> 
> 
> 1) Why is the interrupt load relatively high with polling
> enabled?
> 2) How come 13.9% interrupts are not also in the first
> scenario if their total rate is the same (~8000)?
> 
> Thanks.

The more important questions are:

1) Why are you polling with a NIC that can be precisely set to
interrupt as often or as little as you like?
2) Why do so many people run systems with high network load with
AMD64 builds when its significantly slower to do so? Do you have
google sized databases so you need 64-bit pointers?

As to why you get interrupt load, how do you think that polling is 
implemented? By Magic? You are merely shifting the interrupt load
from the em driver to the software interrupts. Running em drivers
with AIM is essentially the same as polling without the associated
system overhead that polling introduces.

Barney