public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Hannes Reinecke <hare@suse.de>,
	linux-kernel@vger.kernel.org, Andrew Morton <akpm@osdl.org>
Subject: Re: calibrate_migration_costs takes ages on s390
Date: Mon, 13 Feb 2006 11:46:45 +0100	[thread overview]
Message-ID: <20060213104645.GA17173@elte.hu> (raw)
In-Reply-To: <20060213102634.GA4677@osiris.boeblingen.de.ibm.com>


* Heiko Carstens <heiko.carstens@de.ibm.com> wrote:

> The boot sequence on s390 sometimes takes ages and we spend a very 
> long time (up to one or two minutes) in calibrate_migration_costs. The 
> time spent there differs from boot to boot. Also the calculated costs 
> differ a lot. I've seen differences by up to a factor of 15 (yes, 
> factor not percent). Also I doubt that making these measurements make 
> much sense on a completely virtualized architecture where you cannot 
> tell how much cpu time you will get anyway. Is there any workaround or 
> fix available so we can avoid seeing this?

which is the precise kernel version used? We toned down calibration a 
bit recently.

The immediate workaround would be to use the migration_cost=0 boot 
parameter.

Generally, i agree that it makes sense to not calibrate at all on 
virtual platforms. Does the patch below help?  It gives virtual 
platforms a way to provide a default migration cost and thus avoid the 
boot-time calibration altogether. (I have tested it on x86, it does the 
expected thing.) This needs to hit v2.6.16 too.

	Ingo

---------
introduce the CONFIG_DEFAULT_MIGRATION_COST method for an architecture
to set the scheduler migration costs. This turns off automatic detection
of migration costs. Makes sense on virtual platforms, where migration
costs are hard to measure accurately.

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

----

 arch/s390/Kconfig |    4 ++++
 kernel/sched.c    |   13 ++++++++++++-
 2 files changed, 16 insertions(+), 1 deletion(-)

Index: linux-robust-list.q/arch/s390/Kconfig
===================================================================
--- linux-robust-list.q.orig/arch/s390/Kconfig
+++ linux-robust-list.q/arch/s390/Kconfig
@@ -80,6 +80,10 @@ config HOTPLUG_CPU
 	  can be controlled through /sys/devices/system/cpu/cpu#.
 	  Say N if you want to disable CPU hotplug.
 
+config DEFAULT_MIGRATION_COST
+	int
+	default "1000000"
+
 config MATHEMU
 	bool "IEEE FPU emulation"
 	depends on MARCH_G5
Index: linux-robust-list.q/kernel/sched.c
===================================================================
--- linux-robust-list.q.orig/kernel/sched.c
+++ linux-robust-list.q/kernel/sched.c
@@ -5159,7 +5159,18 @@ static void init_sched_build_groups(stru
 #define MAX_DOMAIN_DISTANCE 32
 
 static unsigned long long migration_cost[MAX_DOMAIN_DISTANCE] =
-		{ [ 0 ... MAX_DOMAIN_DISTANCE-1 ] = -1LL };
+		{ [ 0 ... MAX_DOMAIN_DISTANCE-1 ] =
+/*
+ * Architectures may override the migration cost and thus avoid
+ * boot-time calibration. Unit is nanoseconds. Mostly useful for
+ * virtualized hardware:
+ */
+#ifdef CONFIG_DEFAULT_MIGRATION_COST
+			CONFIG_DEFAULT_MIGRATION_COST
+#else
+			-1LL
+#endif
+};
 
 /*
  * Allow override of migration cost - in units of microseconds.

  parent reply	other threads:[~2006-02-13 10:48 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-13 10:26 calibrate_migration_costs takes ages on s390 Heiko Carstens
2006-02-13 10:34 ` David S. Miller
2006-02-13 10:54   ` Ingo Molnar
2006-02-13 20:57     ` David S. Miller
2006-02-13 10:46 ` Ingo Molnar [this message]
2006-02-13 16:13   ` Heiko Carstens
2006-02-13 23:42   ` Olaf Hering
2006-02-14  0:08     ` Olaf Hering
2006-02-14  8:09       ` Heiko Carstens
2006-02-14 10:56         ` Heiko Carstens
2006-02-14 12:35           ` Ingo Molnar
2006-02-14 12:37             ` Ingo Molnar
2006-02-16  6:27   ` Heiko Carstens

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=20060213104645.GA17173@elte.hu \
    --to=mingo@elte.hu \
    --cc=akpm@osdl.org \
    --cc=hare@suse.de \
    --cc=heiko.carstens@de.ibm.com \
    --cc=linux-kernel@vger.kernel.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