Interpreting from top: [intr{irq18: bge0 arcmsr*}]

scotia

scotia

Hi all,

does the following process name from top:

Code: 
[intr{irq18: bge0 arcmsr*}]


mean that bge0 and arcmsr* share irq18? If so, is that bad for a NIC and an HBA to share an IRQ? Or am I thinking of the day when I had to set a jumper on a card before I put it in my PC/XT?

Specifically the line in top was:
Code: 
12 root          -92    -     0K   160K WAIT    0 549:00  33.99% [intr{irq18: bge0 arcmsr*}]

Thanks
 
scotia said:
does the following process name from top:
Code: 
[intr{irq18: bge0 arcmsr*}]
mean that bge0 and arcmsr* share irq18? If so, is that bad for a NIC and an HBA to share an IRQ?
Click to expand...
Yes, apparently they share an interrupt level. You can confirm that in the output of vmstat -i.
You can also try grep "irq 18" /var/run/dmesg.boot and ps -Haxu | grep intr.

Whether it might be bad depends on the interrupt load. Look at the “rate” column of the vmstat(8) output for that interrupt number. If it is rather low (say, a 3-digit number or less), then there shouldn’t be a problem. Also check the “CPU” column in the ps(1) output. Under normal circumstances, interrupt threads should not cause significant CPU load.

Also note that bge(4) supports polling(4). You can enable it with ifconfig(8). It reduces the interrupt load on the interface considerably, and can even improve performance and overall responsiveness of the system.
 
olli@ thanks for the great reply.

Here's vmstat:
Code: 
# vmstat -i
interrupt                          total       rate
irq17: ehci0 ehci1+                   59          0
irq18: bge0 arcmsr*            104228922       6330
irq256: hpet0:t0                16211167        985
irq257: hpet0:t1                16045002        974
irq259: ahci0                   15024654        912
Total                          151509804       9201

The output from ps only shows 0 for the CPU of every process, although when sorting by CPU the top lines are:
Code: 
  UID   PID  PPID CPU PRI NI    VSZ    RSS MWCHAN   STAT TT       TIME COMMAND          USER             PGID   SID JOBC
    0    12     0   0 -92  0      0    160 -        WL    -  148:37.82 [intr/irq18: bge root                0     0    0
    0 32274  1630   0  77  0 271744 267912 -        R+    6   14:20.86 mbuffer -4 -s 12 root            32274  1630    2
    0     0     0   0 -12  0      0  19056 -        DLs   -   32:45.27 [kernel/zio_writ root                0     0    0
    0 32275  1630   0  29  0   7888   3772 -        R+    6    9:11.16 zfs receive -dus root            32274  1630    2


top at the moment shows:
Code: 
   12 root          -92    -     0K   160K CPU1    1 146:28  68.64% [intr{irq18: bge0 arcmsr*}]

This server is on the receiving end of a zfs send. It's receiving roughly 900Mb/s at 72,000pps. It's also sending 20Mb/s at 36,000pps (ACKs obviously).

Again thanks for the informative reply. I'll turn on polling and see what happens (after the zfs send).
 
While I've got you, the man page for bge() only mentions polling in the SEE ALSO section, so I checked out the man page for polling().

Are there any tuneables you recommend fiddling with, or just stick with the defaults? This is a home media NAS so not important at all.

Cheers.
 
I think the default values should be ok. Note that the kernel’s HZ value should be at least 1000 for polling (check sysctl kern.hz). With HZ being 1000, the default settings are suitable for handling up to 150,000 pps.
 
So I ran:
# ifconfig bge0 polling and neither the flags nor the options changed.

Code: 
bge0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=c0099<RXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,VLAN_HWTSO,LINKSTATE>

Should it be obvious somewhere that it's on? I also didn't take a hit with either "polling" or "-polling" which surprised me.

(Sadly the chipset doesn't support >1500 MTU)
 
scotia said:
So I ran:
# ifconfig bge0 polling and neither the flags nor the options changed.
Code: 
bge0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=c0099<RXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,VLAN_HWTSO,LINKSTATE>
Click to expand...
Do you have compiled your kernel with polling support? The “GENERIC” kernel does not have it, unfortunately.
You need to put a line
options DEVICE_POLLING
in your kernel configuration. Then recompile, install and reboot.
 
That explains it then. My kernel is as generic as it gets. If I were to recompile and then enable polling on the interface would it show up in the output?

Thanks.
 
scotia said:
That explains it then. My kernel is as generic as it gets. If I were to recompile and then enable polling on the interface would it show up in the output?
Click to expand...
Yes, the word “POLLING” will be listed in the options line (along with RXCSUM, TXCSUM etc.).
 
Thanks again. It's been so long since I'm compiled a kernel... not hard, I know. But I lose freebsd-update.
 
Code: 
cd /sys/amd64/conf
echo include GENERIC > GENPOLL
echo ident GENPOLL >> GENPOLL
echo options DEVICE_POLLING >> GENPOLL
config GENPOLL
cd ../compile/GENPOLL
make cleandepend && make depend
make && make install
After reboot, check sysctl kern.ident to make sure that the new kernel was booted (“GENPOLL”).
Then you should also see the related variables under sysctl kern.polling, and enabling it with ifconfig(8) should work.
 
You must log in or register to reply here.
Back
Top