what is the performance impact of using "idle=poll"?

Stephane Charette (stephanecharette@telus.net)
Tue, 02 Jul 2002 11:25:27 -0700


I was reading through "The Linux BootPrompt-HowTo" at "http://www.ibiblio.org/mdw/HOWTO/BootPrompt-HOWTO.html".

In section 3.5, I found the following:

The `idle=' Argument

Setting this to `poll' causes the idle loop in the
kernel to poll on the need reschedule flag instead
of waiting for an interrupt to happen. This can
result in an improvement in performance on SMP
systems (albeit at the cost of an increase in power
consumption).

I tried to run a few performance tests with 2.4.19-pre9-vanilla-SMP running on a dual-CPU Athlon 1600MHz box. Idle polling was enabled as evidenced by the message "using polling idle threads" on bootup.

While my tests were limited in nature (webstone against an in-house web server, thus not reproducable within the open community), I saw a performance degrade with the "idle=poll" option instead of seeing any performance increase. In one set of tests, idle=poll resulted in 1% degradation, while another run (with the scheduling patch) showed a 2.6% hit. The actual values of my performance tests are not important -- the trend is what I wish to higlight.

My questions:

1) is this a known issue?
2) Was "idle=poll" an old performance hack that no longer applies to the newer kernels but remains in the code?
3) Should it still valid?
4) Has anyone run benchmarks recently and seen a performance hit with idle=poll, instead of the possible "improvement in performance" as stated in the HOW-TO?

A search on google has shown some fairly recent discussion on the kernel list about idle=poll, but nothing that was either definitive, nor conclusive, especially in regards to performance impacts on an SMP kernel running on an SMP box.

Thanks,

Stephane Charette

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/