Commit 4bbf39c2 authored by Ingo Molnar's avatar Ingo Molnar Committed by Linus Torvalds


Heiko Carstens <> 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.

So 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: default avatarIngo Molnar <>
Signed-off-by: default avatarAndrew Morton <>
Signed-off-by: default avatarLinus Torvalds <>
parent 05efc67d
......@@ -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.
default "1000000"
config MATHEMU
bool "IEEE FPU emulation"
depends on MARCH_G5
......@@ -5058,7 +5058,18 @@ static void init_sched_build_groups(struct sched_group groups[], cpumask_t span,
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:
* Allow override of migration cost - in units of microseconds.
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment