From: "Stephane Charette" <stephanecharette@telus.net>
To: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: what is the performance impact of using "idle=poll"?
Date: Tue, 02 Jul 2002 11:25:27 -0700 [thread overview]
Message-ID: <20020702182259Z316845-685+2263@vger.kernel.org> (raw)
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
reply other threads:[~2002-07-02 18:23 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020702182259Z316845-685+2263@vger.kernel.org \
--to=stephanecharette@telus.net \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®