Add the line options DEVICE_POLLING to the kernel config file, compile and boot this kernel, start one program like 'main () { while (1) { } }' on the otherwise idle machine and watch the load avg. climbing above 1 and eventually reaching 2. For the counter test remove the options DEVICE_POLLING line and watch the load avg. reaching 1 for the same test. Fix: Don't know, I'm no kernel hacker yet. How-To-Repeat: See above
This would appear to be unavoidable with polling, because of what the load average represents. Since it only shows the number of things waiting to run (or, number of things on the run queue), polling would be expected to cause this behavior.
On Sat, 17 Mar 2007, Harrison Grundy wrote: > This would appear to be unavoidable with polling, because of what the > load average represents. Since it only shows the number of things > waiting to run (or, number of things on the run queue), polling would > be expected to cause this behavior. This behaviour (load average 2 with just 1 hog process) happens with polling configured on no devices, and even with no devices capable of supporting polling, but misbehaviour doesn't happen with 0 hog processes (then the load average is 0). Why would polling be expected to do that? I didn't know that polling is what causes this. It is very old misbehaviour (happens in pre-5.2). Bruce