All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Martin J. Bligh" <mbligh@google.com>
To: Peter Williams <pwil3058@bigpond.net.au>
Cc: Con Kolivas <kernel@kolivas.org>, Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
	Andy Whitcroft <apw@shadowen.org>
Subject: Re: -mm seems significanty slower than mainline on kernbench
Date: Sat, 14 Jan 2006 10:48:27 -0800	[thread overview]
Message-ID: <43C9477B.8060709@google.com> (raw)
In-Reply-To: <43C75178.80809@bigpond.net.au>


>
> Attached is a new patch to fix the excessive idle problem.  This patch 
> takes a new approach to the problem as it was becoming obvious that 
> trying to alter the load balancing code to cope with biased load was 
> harder than it seemed.
>
> This approach reverts to the old load values but weights them 
> according to tasks' bias_prio values.  This means that any assumptions 
> by the load balancing code that the load generated by a single task is 
> SCHED_LOAD_SCALE will still hold.  Then, in find_busiest_group(), the 
> imbalance is scaled back up to bias_prio scale so that move_tasks() 
> can move biased load rather than tasks.
>
OK, this one seems to fix the issue that I had, AFAICS. Congrats, and 
thanks,

M.

> One advantage of this is that when there are no non zero niced tasks 
> the processing will be mathematically the same as the original code. 
> Kernbench results from a 2 CPU Celeron 550Mhz system are:
>
> Average Optimal -j 8 Load Run:
> Elapsed Time 1056.16 (0.831102)
> User Time 1906.54 (1.38447)
> System Time 182.086 (0.973386)
> Percent CPU 197 (0)
> Context Switches 48727.2 (249.351)
> Sleeps 27623.4 (413.913)
>
> This indicates that, on average, 98.9% of the total available CPU was 
> used by the build.
>
> Signed-off-by: Peter Williams <pwil3058@bigpond.com.au>
>
> BTW I think that we need to think about a slightly more complex nice 
> to bias mapping function.  The current one gives a nice==19 1/20 of 
> the bias of a nice=0 task but only gives nice=-20 tasks twice the bias 
> of a nice=0 task.  I don't think this is a big problem as the majority 
> of non nice==0 tasks will have positive nice but should be looked at 
> for a future enhancement.
>
> Peter
>
>------------------------------------------------------------------------
>
>Index: MM-2.6.X/kernel/sched.c
>===================================================================
>--- MM-2.6.X.orig/kernel/sched.c	2006-01-13 14:53:34.000000000 +1100
>+++ MM-2.6.X/kernel/sched.c	2006-01-13 15:11:19.000000000 +1100
>@@ -1042,7 +1042,8 @@ void kick_process(task_t *p)
> static unsigned long source_load(int cpu, int type)
> {
> 	runqueue_t *rq = cpu_rq(cpu);
>-	unsigned long load_now = rq->prio_bias * SCHED_LOAD_SCALE;
>+	unsigned long load_now = (rq->prio_bias * SCHED_LOAD_SCALE) /
>+		NICE_TO_BIAS_PRIO(0);
> 
> 	if (type == 0)
> 		return load_now;
>@@ -1056,7 +1057,8 @@ static unsigned long source_load(int cpu
> static inline unsigned long target_load(int cpu, int type)
> {
> 	runqueue_t *rq = cpu_rq(cpu);
>-	unsigned long load_now = rq->prio_bias * SCHED_LOAD_SCALE;
>+	unsigned long load_now = (rq->prio_bias * SCHED_LOAD_SCALE) /
>+		NICE_TO_BIAS_PRIO(0);
> 
> 	if (type == 0)
> 		return load_now;
>@@ -1322,7 +1324,8 @@ static int try_to_wake_up(task_t *p, uns
> 			 * of the current CPU:
> 			 */
> 			if (sync)
>-				tl -= p->bias_prio * SCHED_LOAD_SCALE;
>+				tl -= (p->bias_prio * SCHED_LOAD_SCALE) /
>+					NICE_TO_BIAS_PRIO(0);
> 
> 			if ((tl <= load &&
> 				tl + target_load(cpu, idx) <= SCHED_LOAD_SCALE) ||
>@@ -2159,7 +2162,7 @@ find_busiest_group(struct sched_domain *
> 	}
> 
> 	/* Get rid of the scaling factor, rounding down as we divide */
>-	*imbalance = *imbalance / SCHED_LOAD_SCALE;
>+	*imbalance = (*imbalance * NICE_TO_BIAS_PRIO(0)) / SCHED_LOAD_SCALE;
> 	return busiest;
> 
> out_balanced:
>@@ -2472,7 +2475,8 @@ static void rebalance_tick(int this_cpu,
> 	struct sched_domain *sd;
> 	int i;
> 
>-	this_load = this_rq->prio_bias * SCHED_LOAD_SCALE;
>+	this_load = (this_rq->prio_bias * SCHED_LOAD_SCALE) /
>+		NICE_TO_BIAS_PRIO(0);
> 	/* Update our load */
> 	for (i = 0; i < 3; i++) {
> 		unsigned long new_load = this_load;
>  
>


  parent reply	other threads:[~2006-01-14 18:49 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-11  1:14 -mm seems significanty slower than mainline on kernbench Martin Bligh
2006-01-11  1:31 ` Andrew Morton
2006-01-11  1:41   ` Martin Bligh
2006-01-11  1:48     ` Andrew Morton
2006-01-11  1:49     ` Con Kolivas
2006-01-11  2:38       ` Peter Williams
2006-01-11  3:07         ` Con Kolivas
2006-01-11  3:12           ` Martin Bligh
2006-01-11  3:40           ` Peter Williams
2006-01-11  3:49             ` Con Kolivas
2006-01-11  4:33               ` Peter Williams
2006-01-11  5:14             ` Peter Williams
2006-01-11  6:21               ` Martin J. Bligh
2006-01-11 12:24                 ` Peter Williams
2006-01-11 14:29                   ` Con Kolivas
2006-01-11 22:05                     ` Peter Williams
2006-01-12  0:54                       ` Peter Williams
2006-01-12  1:18                         ` Con Kolivas
2006-01-12  1:29                           ` Peter Williams
2006-01-12  1:36                             ` Con Kolivas
2006-01-12  2:23                               ` Peter Williams
2006-01-12  2:26                                 ` Martin Bligh
2006-01-12  6:39                                   ` Con Kolivas
2006-01-23 19:28                                     ` Martin Bligh
2006-01-24  1:25                                       ` Peter Williams
2006-01-24  3:50                                         ` Peter Williams
2006-01-24  4:41                                           ` Martin J. Bligh
2006-01-24  6:22                                             ` Peter Williams
2006-01-24  6:42                                               ` Martin J. Bligh
2006-01-28 23:20                                                 ` Peter Williams
2006-01-29  0:52                                                   ` Martin J. Bligh
2006-01-12  2:27                                 ` Con Kolivas
2006-01-12  2:04                           ` Martin Bligh
2006-01-12  6:35                             ` Martin J. Bligh
2006-01-12  6:41                               ` Con Kolivas
2006-01-12  6:54                                 ` Peter Williams
2006-01-12 18:39                         ` Martin Bligh
2006-01-12 20:03                           ` Peter Williams
2006-01-12 22:20                             ` Peter Williams
2006-01-13  7:06                               ` Peter Williams
2006-01-13 12:00                                 ` Peter Williams
2006-01-13 16:15                                 ` Martin J. Bligh
2006-01-13 16:26                                 ` Andy Whitcroft
2006-01-13 17:54                                   ` Andy Whitcroft
2006-01-13 20:41                                     ` Martin Bligh
2006-01-14  0:23                                       ` Peter Williams
2006-01-14  5:03                                         ` Nick Piggin
2006-01-14  5:40                                           ` Con Kolivas
2006-01-14  6:05                                             ` Nick Piggin
2006-01-14  5:53                                           ` Peter Williams
2006-01-14  6:13                                             ` Nick Piggin
2006-01-13 22:59                                     ` Peter Williams
2006-01-14 18:48                                 ` Martin J. Bligh [this message]
2006-01-15  0:05                                   ` Peter Williams
2006-01-15  2:04                                     ` Con Kolivas
2006-01-15  2:09                                     ` [PATCH] sched - remove unnecessary smpnice ifdefs Con Kolivas
2006-01-15  3:50                                     ` -mm seems significanty slower than mainline on kernbench Ingo Molnar
2006-01-12  1:25                       ` Peter Williams
2006-01-11  1:52     ` Andrew Morton

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=43C9477B.8060709@google.com \
    --to=mbligh@google.com \
    --cc=akpm@osdl.org \
    --cc=apw@shadowen.org \
    --cc=kernel@kolivas.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=pwil3058@bigpond.net.au \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.