sched: Cleanup cpu_active madness
author黄涛 <huangtao@rock-chips.com>
Thu, 12 Jul 2012 01:46:55 +0000 (09:46 +0800)
committer黄涛 <huangtao@rock-chips.com>
Thu, 12 Jul 2012 01:49:51 +0000 (09:49 +0800)
commitdbc0fca46181dbcaf4a4e9f11e2bb6414cecc5a8
tree80520a2dc6be776fc539c0cd2ff71cfcb7446213
parent8215d8fbbf0cd3b4b65b6c10259ee34c5bc2a3ff
sched: Cleanup cpu_active madness

commit 5fbd036b552f633abb394a319f7c62a5c86a9cd7 upstream.

Stepan found:

CPU0 CPUn

_cpu_up()
  __cpu_up()

boostrap()
  notify_cpu_starting()
  set_cpu_online()
  while (!cpu_active())
    cpu_relax()

<PREEMPT-out>

smp_call_function(.wait=1)
  /* we find cpu_online() is true */
  arch_send_call_function_ipi_mask()

  /* wait-forever-more */

<PREEMPT-in>
  local_irq_enable()

  cpu_notify(CPU_ONLINE)
    sched_cpu_active()
      set_cpu_active()

Now the purpose of cpu_active is mostly with bringing down a cpu, where
we mark it !active to avoid the load-balancer from moving tasks to it
while we tear down the cpu. This is required because we only update the
sched_domain tree after we brought the cpu-down. And this is needed so
that some tasks can still run while we bring it down, we just don't want
new tasks to appear.

On cpu-up however the sched_domain tree doesn't yet include the new cpu,
so its invisible to the load-balancer, regardless of the active state.
So instead of setting the active state after we boot the new cpu (and
consequently having to wait for it before enabling interrupts) set the
cpu active before we set it online and avoid the whole mess.
arch/arm/kernel/smp.c
kernel/sched.c