LKML Archive on
help / color / mirror / Atom feed
From: Ken Chen <>
To: Ingo Molnar <>
Cc: Linux Kernel Mailing List <>
Subject: [patch] restore sched_exec load balance heuristics
Date: Thu, 6 Nov 2008 11:40:28 -0800	[thread overview]
Message-ID: <> (raw)

We've seen long standing performance regression on sys_execve for several
upstream kernels, largely on workload that does heavy execve.  The main
reason for the regression was due to a change in sched_exec load balance
heuristics.  For example, on 2.6.11 kernel, the "exec" task will run on
the same cpu if that is the only task running.  However, 2.6.13 and onward
kernels will go around the sched-domain looking for most idle CPU (which
doesn't treat task exec'ing as an idle CPU).  Thus bouncing the exec'ing
task all over the place which leads to poor CPU cache and numa locality.
(The workload happens to share common data between subsequent exec program).

This execve heuristic was removed in upstream kernel by this git commit:

commit 68767a0ae428801649d510d9a65bb71feed44dd1
Author: Nick Piggin <>
Date:   Sat Jun 25 14:57:20 2005 -0700

[PATCH] sched: schedstats update for balance on fork
Add SCHEDSTAT statistics for sched-balance-fork.

>From the commit description, it appears that deleting the heuristics
was an accident, as the commit is supposedly just for schedstats.

So, restore the sched-exec load balancing if exec'ing task is the only
task running on that specific CPU.  The logic make sense: newly exec
program should continue to run on current CPU as it doesn't change any
load imbalance nor does it help anything by bouncing to another idle
CPU. By keeping on the same CPU, it preserves cache and numa locality.

Signed-off-by: Ken Chen <>

diff --git a/kernel/sched.c b/kernel/sched.c
index e8819bc..4ad1907 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -2873,7 +2873,12 @@ out:
 void sched_exec(void)
-	int new_cpu, this_cpu = get_cpu();
+	int new_cpu, this_cpu;
+	if (this_rq()->nr_running <= 1)
+		return;
+	this_cpu = get_cpu();
 	new_cpu = sched_balance_self(this_cpu, SD_BALANCE_EXEC);
 	if (new_cpu != this_cpu)

             reply	other threads:[~2008-11-06 19:40 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-06 19:40 Ken Chen [this message]
2008-11-06 20:07 ` [patch] restore sched_exec load balance heuristics Ingo Molnar
2008-11-06 20:32   ` Ken Chen
2008-11-06 20:38     ` Ingo Molnar
2008-11-06 20:49     ` Chris Friesen
2008-11-10  8:50   ` Peter Zijlstra
2008-11-10  9:29     ` Ingo Molnar
2008-11-10 12:54       ` Peter Zijlstra

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* 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;
as well as URLs for NNTP newsgroup(s).