From: "Chen, Kenneth W" <kenneth.w.chen@intel.com>
To: linux-kernel@vger.kernel.org, linux-ia64@vger.kernel.org
Cc: "Luck, Tony" <tony.luck@intel.com>,
'Nick Piggin' <nickpiggin@yahoo.com.au>,
"Seth, Rohit" <rohit.seth@intel.com>,
'Linus Torvalds' <torvalds@osdl.org>,
akpm@osdl.org
Subject: [patch] cpu_idle performance bug fix
Date: Tue, 15 Nov 2005 22:37:05 +0000 [thread overview]
Message-ID: <200511152237.jAFMb5g14072@unix-os.sc.intel.com> (raw)
All,
Our performance validation on 2.6.15-rc1 caught a disastrous
performance regression with netperf (-98%) and volanomark (-58%)
compares to previous kernel version 2.6.14-git7. See the following
chart (result group 1 & 2).
http://kernel-perf.sourceforge.net/results.machine_id&.html
We have root caused it to this changeset: http://tinyurl.com/cetoa
This changeset broke the ia64 task resched notification. In
sched.c:resched_task(), a reschedule IPI is conditioned upon
TIF_POLLING_NRFLAG. However, the above changeset unconditionally
set the polling thread flag for idle tasks regardless whether
pal_halt_light is in use or not. As a result, resched IPI is not
sent from resched_task(). And since the default behavior on ia64
is to use pal_halt_light, we end up delaying the rescheduling task
until next timer tick, and thus cause the performance regression.
Here is the patch to fix the performance bug. I'm glad our performance
suite is turning up bad performance bug like this in time.
Tony, since this is such a catastrophic performance failure, please
consider merge this fix for 2.6.15-rc2.
Signed-off-by: Ken Chen <kenneth.w.chen@intel.com>
--- ./arch/ia64/kernel/process.c.orig 2005-11-15 11:43:30.019045450 -0800
+++ ./arch/ia64/kernel/process.c 2005-11-15 12:15:27.116678215 -0800
@@ -202,12 +202,9 @@ default_idle (void)
{
local_irq_enable();
while (!need_resched()) {
- if (can_do_pal_halt) {
- local_irq_disable();
- if (!need_resched())
- safe_halt();
- local_irq_enable();
- } else
+ if (can_do_pal_halt)
+ safe_halt();
+ else
cpu_relax();
}
}
@@ -272,10 +269,14 @@ cpu_idle (void)
{
void (*mark_idle)(int) = ia64_mark_idle;
int cpu = smp_processor_id();
- set_thread_flag(TIF_POLLING_NRFLAG);
/* endless idle loop with no priority at all */
while (1) {
+ if (can_do_pal_halt)
+ clear_thread_flag(TIF_POLLING_NRFLAG);
+ else
+ set_thread_flag(TIF_POLLING_NRFLAG);
+
if (!need_resched()) {
void (*idle)(void);
#ifdef CONFIG_SMP
reply other threads:[~2005-11-15 22:37 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=200511152237.jAFMb5g14072@unix-os.sc.intel.com \
--to=kenneth.w.chen@intel.com \
--cc=akpm@osdl.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nickpiggin@yahoo.com.au \
--cc=rohit.seth@intel.com \
--cc=tony.luck@intel.com \
--cc=torvalds@osdl.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