Polling causes 100% CPU

ajg

Hi,

I also observed the problem. CPU is persistently running 100% since I move to nanobsd. The problem disappears pooling is disabled.
This reappears when pooling is enable. The problem is reproducible and consistent.

Using nanobsd RC 1.2.3 oct 19 2009 build. 1G image.

Can anyone development check on this if it's a bug?
Using Alix2d3. with latest bios ALIX tinyBIOS v0.99h

ajg

cmb

There is some kind of problem with polling, it pegs the CPU at 100%. It's not a nanobsd issue, full installs do the same. Looks like a regression in FreeBSD 7.2.

You rarely want to use polling anyway, I would just leave it disabled. Seeing if we can find an easy solution.

xbipin

i have the device polling disabled but as soon as i make any other modifications, it starts using 100% CPU

wonslung

i can second this. I was noticing 50% cpu usage with little traffic and 100% with heavy traffic, i thought this was due to ntop becuase this is what was showing the highest in TOP, but cpu drops to a normal level (4-12%) with polling disabled.

Any reason why this would be so?

jimp

@wonslung:

i can second this. I was noticing 50% cpu usage with little traffic and 100% with heavy traffic, i thought this was due to ntop becuase this is what was showing the highest in TOP, but cpu drops to a normal level (4-12%) with polling disabled.

Any reason why this would be so?

Try running:
top -SH

That way it will show system and other normally hidden threads.

Ter Roshak

device polling enabled starts up the system process "idle_poll" which
uses up all your free cpu time for some kind of "wait for the next time i can poll some data"
there is an option you can tweak the polling interval in HZ which default value is 1000,
so idle_poll will 1000 times a second poll for data…

i don't know exactly what it does in the meantime with my cpu load so i just
switched it off... working perfectly with a slightly higher latency...

sysctl kern.polling.idle_poll=0

solves this problem...

there are other ways tuning up polling for you.. but for now it should help..

jimp

Ter Roshak,

Tweaking that sysctl may not do what you want. From the polling(4) man page:

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.

wonslung

@jimp:

@wonslung:

i can second this. I was noticing 50% cpu usage with little traffic and 100% with heavy traffic, i thought this was due to ntop becuase this is what was showing the highest in TOP, but cpu drops to a normal level (4-12%) with polling disabled.

Any reason why this would be so?

Try running:
top -SH

That way it will show system and other normally hidden threads.

yes, i saw this shortly after i posted. I indead have a 100% idle_poll process

Guest

i have in one box squid over 60% all the time (idle is 9%, and all is near 100%). before everything was most of time below 60%. only change is that i enlarged disk cache from 500MB to 40GB

Wilson Chuah

Just want to add that I have this problem with the pfsense box I have at home running 1.2.3 RC3, I didn't have this problem in RC1.

I'm running on an old Acer PC with two similar DLINK NICs (don't remember the specific model). Whenever I turn off device polling I start to have collisions and network traffic problems so I need it enabled.

stephenyeong

I have this issue too, using latest snapshot version of 1.2.3rc3

I just comment out one line on folling file to make the box not apply idle_poll again.
/etc/inc/pfsense-utils.inc
line 1103
mwexec("/sbin/sysctl kern.polling.idle_poll=1");

jimp

@stephenyeong:

I have this issue too, using latest snapshot version of 1.2.3rc3

I just comment out one line on folling file to make the box not apply idle_poll again.
/etc/inc/pfsense-utils.inc
line 1103
mwexec("/sbin/sysctl kern.polling.idle_poll=1");

By doing that, you never enabled polling. That sysctl is what actually enables polling.

Polling works by using idle CPU cycles to poll instead of using interrupts.

It is not "stealing" or "hogging" your CPU time. That is just how it works. There is no problem here, it's just a cosmetic difference in how CPU time is reported.