1. 11 8月, 2008 3 次提交
    • D
      sched, cpu hotplug: fix set_cpus_allowed() use in hotplug callbacks · 279ef6bb
      Dmitry Adamushko 提交于
      Mark Langsdorf reported:
      
      > One of my co-workers noticed that the powernow-k8
      > driver no longer restarts when a CPU core is
      > hot-disabled and then hot-enabled on AMD quad-core
      > systems.
      >
      > The following comands work fine on 2.6.26 and fail
      > on 2.6.27-rc1:
      >
      > echo 0 > /sys/devices/system/cpu/cpu3/online
      > echo 1 > /sys/devices/system/cpu/cpu3/online
      > find /sys -name cpufreq
      >
      > For 2.6.26, the find will return a cpufreq
      > directory for each processor.  In 2.6.27-rc1,
      > the cpu3 directory is missing.
      >
      > After digging through the code, the following
      > logic is failing when the core is hot-enabled
      > at runtime.  The code works during the boot
      > sequence.
      >
      >       cpumask_t = current->cpus_allowed;
      >       set_cpus_allowed_ptr(current, &cpumask_of_cpu(cpu));
      >       if (smp_processor_id() != cpu)
      >               return -ENODEV;
      
      So set the CPU active before calling the CPU_ONLINE notifier chain,
      there are a handful of notifiers that use set_cpus_allowed().
      
      This fix also solves the problem with x86-microcode. I've sent
      alternative patches for microcode, but as this "rely on
      set_cpus_allowed_ptr() being workable in cpu-hotplug(CPU_ONLINE, ...)"
      assumption seems to be more broad than what we thought, perhaps this fix
      should be applied.
      
      With this patch we define that by the moment CPU_ONLINE is being sent,
      a 'cpu' is online and ready for tasks to be migrated onto it.
      Signed-off-by: NDmitry Adamushko <dmitry.adamushko@gmail.com>
      Reported-by: NMark Langsdorf <mark.langsdorf@amd.com>
      Tested-by: NMark Langsdorf <mark.langsdorf@amd.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      279ef6bb
    • M
      sched: fix mysql+oltp regression · 77ae6513
      Mike Galbraith 提交于
      Defer commit 6d299f1b to the next release.
      
      Testing of the tip/sched/clock tree revealed a mysql+oltp regression
      which bisection eventually traced back to this commit in mainline.
      
      Pertinent test results:  Three run sysbench averages, throughput units
      in read/write requests/sec.
      
      clients         1     2     4     8    16    32    64
      6e0534f2      9646 17876 34774 33868 32230 30767 29441
      2.6.26.1     9112 17936 34652 33383 31929 30665 29232
      6d299f1b      9112 14637 28370 33339 32038 30762 29204
      
      Note: subsequent commits hide the majority of this regression until you
      apply the clock fixes, at which time it reemerges at full magnitude.
      
      We cannot see anything bad about the change itself so we defer it to the
      next release until this problem is fully analysed.
      Signed-off-by: NMike Galbraith <efault@gmx.de>
      Acked-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Gregory Haskins <ghaskins@novell.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      77ae6513
    • I
      Merge branch 'linus' into sched/urgent · 251a169c
      Ingo Molnar 提交于
      251a169c
  2. 09 8月, 2008 16 次提交
  3. 08 8月, 2008 21 次提交