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



## scotia (Sep 23, 2020)

Hi all,

does the following process name from top:


```
[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:

```
12 root          -92    -     0K   160K WAIT    0 549:00  33.99% [intr{irq18: bge0 arcmsr*}]
```

Thanks


----------



## olli@ (Sep 23, 2020)

scotia said:


> does the following process name from top:
> 
> ```
> [intr{irq18: bge0 arcmsr*}]
> ...


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.


----------



## scotia (Sep 23, 2020)

olli@ thanks for the great reply.

Here's `vmstat`:

```
# 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:

```
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:

```
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).


----------



## scotia (Sep 23, 2020)

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.


----------



## olli@ (Sep 23, 2020)

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.


----------



## scotia (Sep 23, 2020)

So I ran:
`# ifconfig bge0 polling` and neither the flags nor the options changed.


```
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)


----------



## olli@ (Sep 23, 2020)

scotia said:


> So I ran:
> `# ifconfig bge0 polling` and neither the flags nor the options changed.
> 
> ```
> ...


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.


----------



## scotia (Sep 23, 2020)

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.


----------



## olli@ (Sep 23, 2020)

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?


Yes, the word “POLLING” will be listed in the options line (along with RXCSUM, TXCSUM etc.).


----------



## scotia (Sep 23, 2020)

Thanks again.  It's been so long since I'm compiled a kernel...  not hard, I know.  But I lose freebsd-update.


----------



## olli@ (Sep 23, 2020)

```
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.


----------

