Set kern.polling.idle_poll to 1 to match the FreeBSD 4.x behavior. Message from the mailing list:
"Polling and kern.polling.idle_poll" -- freebsd-net -- Jun 30 2009
"A while back I upgraded some old gateways from FreeBSD 4.x to FreeBSD 6.x. I thought the upgrade had went smoothly, but a while later I started having users complaining about throughput. Luckly I still had a backup of the FreebSD 4.x install. Did some throughput tests with iperf. Low and behold 4.x appeared to have twice the throughput. After lots of experimenting I determined that turning off polling fixed the issue. So I started digging through the kernel code to see what had changed in the polling logic. Finally arived at the fact that "kern.polling.idle_poll" defaults to 1 in 4.x and 0 in 6.x and above. Turning polling back on with idle-poll enabled fixed the performance issue.
The man page for polling states: kern.polling.idle_poll Controls if polling is enabled in the idle loop. There are no reasons (other than power saving or bugs in the scheduler's han- dling of idle priority kernel threads) to disable this."
Set kern.polling.idle_poll to 1 to match the FreeBSD 4.x behavior. Message from the mailing list:
"Polling and kern.polling.idle_poll" -- freebsd-net -- Jun 30 2009
"A while back I upgraded some old gateways from FreeBSD 4.x to FreeBSD 6.x.
I thought the upgrade had went smoothly, but a while later I started having
users complaining about throughput. Luckly I still had a backup of the
FreebSD 4.x install. Did some throughput tests with iperf. Low and behold
4.x appeared to have twice the throughput. After lots of experimenting I
determined that turning off polling fixed the issue. So I started digging
through the kernel code to see what had changed in the polling logic.
Finally arived at the fact that "kern.polling.idle_poll" defaults to 1 in
4.x and 0 in 6.x and above. Turning polling back on with idle-poll enabled
fixed the performance issue.
The man page for polling states:
kern.polling.idle_poll
Controls if polling is enabled in the idle loop. There are no
reasons (other than power saving or bugs in the scheduler's han-
dling of idle priority kernel threads) to disable this."