public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>,
	Ingo Molnar <mingo@redhat.com>,
	linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@osdl.org>, Linus Torvalds <torvalds@osdl.org>
Subject: Re: boot-time slowdown for measure_migration_cost
Date: Mon, 30 Jan 2006 20:24:38 +0100	[thread overview]
Message-ID: <20060130192438.GA29129@elte.hu> (raw)
In-Reply-To: <20060130185301.GA4622@agluck-lia64.sc.intel.com>


* Luck, Tony <tony.luck@intel.com> wrote:

> Doing this drops the time to compute the value from 15.58s to 10.39s, 
> while the value of migration_cost changes from 10112 to 9909.
>
> > - in kernel/sched.c, change this line:
> >                 size = size * 20 / 19;
> >   to:
> >                 size = size * 10 / 9;
>
> Doing this instead of changing ITERATIONS makes the computation take 
> 7.79s and the computed migration_cost is 9987.
>
> Doing both gets the time down to 5.20s, and the migration_cost=9990.

ok, that's good enough i think - we could certainly do the patch below 
in v2.6.16.

> On the plus side Prarit's results show that this time isn't scaling 
> with NR_CPUS ... apparently just cache size and number of domains are 
> significant in the time to compute.

yes, this comes from the algorithm, it only computes once per distance 
(and uses the cached value from then on), independently of the number of 
CPUs.

	Ingo

---
reduce the amount of time the migration cost calculations cost during 
bootup.

Signed-off-by: Ingo Molnar <mingo@elte.hu>

--- linux/kernel/sched.c.orig
+++ linux/kernel/sched.c
@@ -5141,7 +5141,7 @@ static void init_sched_build_groups(stru
 #define SEARCH_SCOPE		2
 #define MIN_CACHE_SIZE		(64*1024U)
 #define DEFAULT_CACHE_SIZE	(5*1024*1024U)
-#define ITERATIONS		2
+#define ITERATIONS		1
 #define SIZE_THRESH		130
 #define COST_THRESH		130
 
@@ -5480,9 +5480,9 @@ static unsigned long long measure_migrat
 				break;
 			}
 		/*
-		 * Increase the cachesize in 5% steps:
+		 * Increase the cachesize in 10% steps:
 		 */
-		size = size * 20 / 19;
+		size = size * 10 / 9;
 	}
 
 	if (migration_debug)

  reply	other threads:[~2006-01-30 19:24 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-27 21:03 boot-time slowdown for measure_migration_cost Bjorn Helgaas
2006-01-30 17:21 ` Ingo Molnar
2006-01-30 18:53   ` Luck, Tony
2006-01-30 19:24     ` Ingo Molnar [this message]
2006-01-30 20:00       ` Luck, Tony
2006-01-30 20:43         ` Prarit Bhargava
2006-01-30 20:52           ` Prarit Bhargava
2006-01-30 20:43     ` John Hawkes
2006-01-30 19:26   ` Chen, Kenneth W
  -- strict thread matches above, loose matches on Subject: below --
2006-01-27 21:48 Luck, Tony
2006-01-27 22:08 ` Prarit Bhargava
2006-02-01  0:50 Chuck Ebbert

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=20060130192438.GA29129@elte.hu \
    --to=mingo@elte.hu \
    --cc=akpm@osdl.org \
    --cc=bjorn.helgaas@hp.com \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.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