mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Theurer <habanero@us.ibm.com>
To: linux-kernel@vger.kernel.org
Cc: kernel@kolivas.org, pwil3058@bigpond.net,
	nickpiggin@yahoo.com.au, mingo@elte.hu, kenneth.w.chen@intel.com,
	akpm@osdl.org
Subject: Re: Default cache_hot_time value back to 10ms
Date: Thu, 7 Oct 2004 10:58:53 -0500	[thread overview]
Message-ID: <200410071058.53618.habanero@us.ibm.com> (raw)
In-Reply-To: <200410071028.01931.habanero@us.ibm.com>

[-- Attachment #1: Type: text/plain, Size: 2973 bytes --]

> OK... Well Andrew as I said I'd be happy for this to go in. I'd be *extra*
> happy if Judith ran a few of those dbt thingy tests which had been
> sensitive to idle time. Can you ask her about that? or should I?
>
> > As a side note, I'd like to get involved on future scheduler tuning
>
> experiments,
>
> > we have fair amount of benchmark environments where we can validate
> > things
>
> across
>
> > various kind of workload, i.e., db, java, cpu, etc.  Thanks.
>
> That would be very welcome indeed. We have a big backlog of scheduler
> things to go in after 2.6.9 is released (although not many of them change
> the runtime behaviour IIRC). After that, I have some experimental
> performance work that could use wider testing. After *that*, the
> multiprocessor scheduler will in a state where 2.6 shouldn't need much more
> work, so we can concentrate on just tuning the dials.

I'd like to add some comments as well:

1) We are seeing similar problems with that "well known" DB transaction 
benchmark, as well as another well known benchmark measuring multi-tier J2EE 
server performance.  Both problems are with load balancing.  It's not quite 
the same situation.  We have too much idle time and not enough throughput.  
Giving a more aggressive idle balance has helped there.  The 3 areas we have 
changed at:

wake_idle()  -find the first idle cpu, statring with cpu->sd and moving up the 
sd's as needed.  Modify SD_NODE_INIT.flags and SD_CPU_INIT.flags to include 
SD_WAKE_IDLE.  Now, if there is an idle cpu (and task->cpu is busy), we move 
it to the closest idle cpu.

can_migrate() put back (again) the aggressive idle condition in can_migrate().  
Do not look at task_hot when we have an idle cpu.

idle_balance() / SD_NODE_INIT   add SD_BALANCE_NEWIDLE to SD_NODE_INIT.flags 
so a newly idle_balance can try to balance from an appropriate cpu, first a 
cpu close to it, then farther out.

(the above changes IMO could also pave the way for removing timer based -idle- 
balances)

IMO, I don't think idle cpus should play by the exact same rules as busy ones 
when load balacing.  I am not saying the only answer is not looking at cache 
warmth at all, but maybe a much more relaxed policy.

Also, finding (at boot time) the best cache_hot_time is a step in the right 
direction, but I have to wonder it cache_hot() is really doing the right 
thing.  It looks like all cache_hot does is decide this task is cache hot 
because it ran recently.  Who's to say the task got cache warm in the first 
place?  Shouldn't we be looking at both how long ago it ran and the length of 
time it ran?  Some of these workloads have very high transaction rates, and 
in turn have very high context switch rates.  I would be surprised if many of 
the tasks got more than enough continuous run time to get good cache warmth 
anyway.  I am all for testing chace warmth, but I think we should start 
looking at more than just how long ago the task ran.

-Andrew Theurer




[-- Attachment #2: 100-wake_idle-patch.269-rc3 --]
[-- Type: text/x-diff, Size: 2668 bytes --]

diff -Naurp linux-2.6.9-rc3/kernel/sched.c linux-2.6.9-rc3-wake_idle/kernel/sched.c
--- linux-2.6.9-rc3/kernel/sched.c	2004-10-09 05:59:47.000000000 -0700
+++ linux-2.6.9-rc3-wake_idle/kernel/sched.c	2004-10-11 00:57:28.590909272 -0700
@@ -393,7 +393,8 @@ struct sched_domain {
 	.flags			= SD_BALANCE_NEWIDLE	\
 				| SD_BALANCE_EXEC	\
 				| SD_WAKE_AFFINE	\
-				| SD_WAKE_BALANCE,	\
+				| SD_WAKE_BALANCE	\
+				| SD_WAKE_IDLE,		\
 	.last_balance		= jiffies,		\
 	.balance_interval	= 1,			\
 	.nr_balance_failed	= 0,			\
@@ -413,7 +414,8 @@ struct sched_domain {
 	.cache_nice_tries	= 1,			\
 	.per_cpu_gain		= 100,			\
 	.flags			= SD_BALANCE_EXEC	\
-				| SD_WAKE_BALANCE,	\
+				| SD_WAKE_BALANCE	\
+				| SD_WAKE_IDLE,		\
 	.last_balance		= jiffies,		\
 	.balance_interval	= 1,			\
 	.nr_balance_failed	= 0,			\
@@ -1066,35 +1068,30 @@ static inline unsigned long target_load(
 #endif
 
 /*
- * wake_idle() is useful especially on SMT architectures to wake a
- * task onto an idle sibling if we would otherwise wake it onto a
- * busy sibling.
+ * wake_idle() will wake a task on an idle cpu if task->cpu is
+ * not idle and and idle cpu is available.  The span of cpus to
+ * search is the top most sched domain with SD_BALANCE_EXEC.
  *
  * Returns the CPU we should wake onto.
  */
 #if defined(ARCH_HAS_SCHED_WAKE_IDLE)
 static int wake_idle(int cpu, task_t *p)
 {
-	cpumask_t tmp;
-	runqueue_t *rq = cpu_rq(cpu);
-	struct sched_domain *sd;
+	cpumask_t cpumask;
+	struct sched_domain *sd = NULL;
 	int i;
 
-	if (idle_cpu(cpu))
-		return cpu;
-
-	sd = rq->sd;
-	if (!(sd->flags & SD_WAKE_IDLE))
-		return cpu;
-
-	cpus_and(tmp, sd->span, cpu_online_map);
-	cpus_and(tmp, tmp, p->cpus_allowed);
-
-	for_each_cpu_mask(i, tmp) {
-		if (idle_cpu(i))
-			return i;
+	for_each_domain(cpu, sd) {
+		if (sd->flags & SD_WAKE_IDLE) {
+			cpus_and(cpumask, sd->span, cpu_online_map);
+			cpus_and(cpumask, cpumask, p->cpus_allowed);
+			for_each_cpu_mask(i, cpumask) {
+				if (idle_cpu(i))
+					return i;
+			}
+		}
+		else break;
 	}
-
 	return cpu;
 }
 #else
@@ -1205,10 +1202,12 @@ static int try_to_wake_up(task_t * p, un
 	new_cpu = cpu; /* Could not wake to this_cpu. Wake to cpu instead */
 out_set_cpu:
 	schedstat_inc(rq, ttwu_attempts);
-	new_cpu = wake_idle(new_cpu, p);
-	if (new_cpu != cpu && cpu_isset(new_cpu, p->cpus_allowed)) {
-		schedstat_inc(rq, ttwu_moved);
-		set_task_cpu(p, new_cpu);
+	if (!idle_cpu(cpu)) {
+		new_cpu = wake_idle(new_cpu, p);
+		if (new_cpu != cpu) {
+			schedstat_inc(rq, ttwu_moved);
+			set_task_cpu(p, new_cpu);
+		}
 		task_rq_unlock(rq, &flags);
 		/* might preempt at this point */
 		rq = task_rq_lock(p, &flags);

[-- Attachment #3: 120-new_idle-patch.269-rc3 --]
[-- Type: text/x-diff, Size: 627 bytes --]

diff -Naurp linux-2.6.9-rc3-wake_idle-can_migrate/kernel/sched.c linux-2.6.9-rc3-wake_idle-can_migrate-newidle/kernel/sched.c
--- linux-2.6.9-rc3-wake_idle-can_migrate/kernel/sched.c	2004-10-11 01:11:58.016917328 -0700
+++ linux-2.6.9-rc3-wake_idle-can_migrate-newidle/kernel/sched.c	2004-10-11 01:24:05.826894464 -0700
@@ -413,7 +413,8 @@ struct sched_domain {
 	.cache_hot_time		= (10*1000000),		\
 	.cache_nice_tries	= 1,			\
 	.per_cpu_gain		= 100,			\
-	.flags			= SD_BALANCE_EXEC	\
+	.flags			= SD_BALANCE_NEWIDLE	\
+				| SD_BALANCE_EXEC	\
 				| SD_WAKE_BALANCE	\
 				| SD_WAKE_IDLE,		\
 	.last_balance		= jiffies,		\

[-- Attachment #4: 110-can_migrate-patch.269-rc3 --]
[-- Type: text/x-diff, Size: 719 bytes --]

diff -Naurp linux-2.6.9-rc3-wake_idle/kernel/sched.c linux-2.6.9-rc3-wake_idle-can_migrate/kernel/sched.c
--- linux-2.6.9-rc3-wake_idle/kernel/sched.c	2004-10-11 00:57:28.590909272 -0700
+++ linux-2.6.9-rc3-wake_idle-can_migrate/kernel/sched.c	2004-10-11 01:11:58.016917328 -0700
@@ -1780,14 +1780,8 @@ int can_migrate_task(task_t *p, runqueue
 		return 0;
 	if (!cpu_isset(this_cpu, p->cpus_allowed))
 		return 0;
-
-	/* Aggressive migration if we've failed balancing */
-	if (idle == NEWLY_IDLE ||
-			sd->nr_balance_failed < sd->cache_nice_tries) {
-		if (task_hot(p, rq->timestamp_last_tick, sd))
-			return 0;
-	}
-
+	if (idle == NOT_IDLE && task_hot(p, rq->timestamp_last_tick, sd))
+		return 0;
 	return 1;
 }
 

       reply	other threads:[~2004-10-07 16:12 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200410071028.01931.habanero@us.ibm.com>
2004-10-07 15:58 ` Andrew Theurer [this message]
2004-10-08  9:47   ` Nick Piggin
2004-10-08 14:11     ` Andrew Theurer
2004-10-07 18:44 Albert Cahalan
  -- strict thread matches above, loose matches on Subject: below --
2004-10-06  0:42 Chen, Kenneth W
2004-10-06  0:47 ` Con Kolivas
2004-10-06  1:02   ` Nick Piggin
2004-10-06  0:58 ` Nick Piggin
2004-10-06  3:55 ` Andrew Morton
2004-10-06  4:30   ` Nick Piggin
2004-10-06  4:51     ` Andrew Morton
2004-10-06  5:00       ` Nick Piggin
2004-10-06  5:09         ` Andrew Morton
2004-10-06  5:21           ` Nick Piggin
2004-10-06  5:33             ` Andrew Morton
2004-10-06  5:46               ` Nick Piggin
2004-10-06  5:52       ` Chen, Kenneth W
2004-10-06 19:27       ` Chen, Kenneth W
2004-10-06 19:39         ` Andrew Morton
2004-10-06 20:38           ` Chen, Kenneth W
2004-10-06 20:43             ` Andrew Morton
2004-10-06 23:14               ` Chen, Kenneth W
2004-10-07  2:26                 ` Nick Piggin
2004-10-07  6:29                 ` Ingo Molnar
2004-10-07  7:08                   ` Jeff Garzik
2004-10-07  7:26                     ` Ingo Molnar
2004-10-06 20:50             ` Ingo Molnar
2004-10-06 21:03               ` Chen, Kenneth W
2004-10-06  7:48 ` Ingo Molnar
2004-10-06 17:18   ` Chen, Kenneth W
2004-10-06 19:55     ` Ingo Molnar
2004-10-06 22:46     ` Peter Williams

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=200410071058.53618.habanero@us.ibm.com \
    --to=habanero@us.ibm.com \
    --cc=akpm@osdl.org \
    --cc=kenneth.w.chen@intel.com \
    --cc=kernel@kolivas.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=nickpiggin@yahoo.com.au \
    --cc=pwil3058@bigpond.net \
    /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®