1. 05 11月, 2011 1 次提交
  2. 26 7月, 2011 1 次提交
    • A
      notifiers: cpu: move cpu notifiers into cpu.h · 80f1ff97
      Amerigo Wang 提交于
      We presently define all kinds of notifiers in notifier.h.  This is not
      necessary at all, since different subsystems use different notifiers, they
      are almost non-related with each other.
      
      This can also save much build time.  Suppose I add a new netdevice event,
      really I don't have to recompile all the source, just network related.
      Without this patch, all the source will be recompiled.
      
      I move the notify events near to their subsystem notifier registers, so
      that they can be found more easily.
      
      This patch:
      
      It is not necessary to share the same notifier.h.
      Signed-off-by: NWANG Cong <amwang@redhat.com>
      Cc: David Miller <davem@davemloft.net>
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      80f1ff97
  3. 11 11月, 2010 1 次提交
  4. 29 6月, 2010 1 次提交
    • T
      workqueue: reimplement CPU hotplugging support using trustee · db7bccf4
      Tejun Heo 提交于
      Reimplement CPU hotplugging support using trustee thread.  On CPU
      down, a trustee thread is created and each step of CPU down is
      executed by the trustee and workqueue_cpu_callback() simply drives and
      waits for trustee state transitions.
      
      CPU down operation no longer waits for works to be drained but trustee
      sticks around till all pending works have been completed.  If CPU is
      brought back up while works are still draining,
      workqueue_cpu_callback() tells trustee to step down and tell workers
      to rebind to the cpu.
      
      As it's difficult to tell whether cwqs are empty if it's freezing or
      frozen, trustee doesn't consider draining to be complete while a gcwq
      is freezing or frozen (tracked by new GCWQ_FREEZING flag).  Also,
      workers which get unbound from their cpu are marked with WORKER_ROGUE.
      
      Trustee based implementation doesn't bring any new feature at this
      point but it will be used to manage worker pool when dynamic shared
      worker pool is implemented.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      db7bccf4
  5. 09 6月, 2010 2 次提交
    • T
      sched: adjust when cpu_active and cpuset configurations are updated during cpu on/offlining · 3a101d05
      Tejun Heo 提交于
      Currently, when a cpu goes down, cpu_active is cleared before
      CPU_DOWN_PREPARE starts and cpuset configuration is updated from a
      default priority cpu notifier.  When a cpu is coming up, it's set
      before CPU_ONLINE but cpuset configuration again is updated from the
      same cpu notifier.
      
      For cpu notifiers, this presents an inconsistent state.  Threads which
      a CPU_DOWN_PREPARE notifier expects to be bound to the CPU can be
      migrated to other cpus because the cpu is no more inactive.
      
      Fix it by updating cpu_active in the highest priority cpu notifier and
      cpuset configuration in the second highest when a cpu is coming up.
      Down path is updated similarly.  This guarantees that all other cpu
      notifiers see consistent cpu_active and cpuset configuration.
      
      cpuset_track_online_cpus() notifier is converted to
      cpuset_update_active_cpus() which just updates the configuration and
      now called from cpuset_cpu_[in]active() notifiers registered from
      sched_init_smp().  If cpuset is disabled, cpuset_update_active_cpus()
      degenerates into partition_sched_domains() making separate notifier
      for !CONFIG_CPUSETS unnecessary.
      
      This problem is triggered by cmwq.  During CPU_DOWN_PREPARE, hotplug
      callback creates a kthread and kthread_bind()s it to the target cpu,
      and the thread is expected to run on that cpu.
      
      * Ingo's test discovered __cpuinit/exit markups were incorrect.
        Fixed.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Acked-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Paul Menage <menage@google.com>
      3a101d05
    • T
      sched: define and use CPU_PRI_* enums for cpu notifier priorities · 50a323b7
      Tejun Heo 提交于
      Instead of hardcoding priority 10 and 20 in sched and perf, collect
      them into CPU_PRI_* enums.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Acked-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      50a323b7
  6. 09 12月, 2009 2 次提交
    • G
      powerpc/pseries: Serialize cpu hotplug operations during deactivate Vs deallocate · 51badebd
      Gautham R Shenoy 提交于
      Currently the cpu-allocation/deallocation process comprises of two steps:
      - Set the indicators and to update the device tree with DLPAR node
        information.
      
      - Online/offline the allocated/deallocated CPU.
      
      This is achieved by writing to the sysfs tunables "probe" during allocation
      and "release" during deallocation.
      
      At the sametime, the userspace can independently online/offline the CPUs of
      the system using the sysfs tunable "online".
      
      It is quite possible that when a userspace tool offlines a CPU
      for the purpose of deallocation and is in the process of updating the device
      tree, some other userspace tool could bring the CPU back online by writing to
      the "online" sysfs tunable thereby causing the deallocate process to fail.
      
      The solution to this is to serialize writes to the "probe/release" sysfs
      tunable with the writes to the "online" sysfs tunable.
      
      This patch employs a mutex to provide this serialization, which is a no-op on
      all architectures except PPC_PSERIES
      Signed-off-by: NGautham R Shenoy <ego@in.ibm.com>
      Acked-by: NVaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      51badebd
    • N
      sysfs/cpu: Add probe/release files · 12633e80
      Nathan Fontenot 提交于
      Version 3 of this patch is updated with documentation added to
      Documentation/ABI.  There are no changes to any of the C code from v2
      of the patch.
      
      In order to support kernel DLPAR of CPU resources we need to provide an
      interface to add (probe) and remove (release) the resource from the system.
      This patch Creates new generic probe and release sysfs files to facilitate
      cpu probe/release.  The probe/release interface provides for allowing each
      arch to supply their own routines for implementing the backend of adding
      and removing cpus to/from the system.
      
      This also creates the powerpc specific stubs to handle the arch callouts
      from writes to the sysfs files.
      
      The creation and use of these files is regulated by the
      CONFIG_ARCH_CPU_PROBE_RELEASE option so that only architectures that need the
      capability will have the files created.
      Signed-off-by: NNathan Fontenot <nfont@austin.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      12633e80
  7. 16 8月, 2009 1 次提交
  8. 23 6月, 2009 1 次提交
  9. 03 4月, 2009 1 次提交
  10. 09 9月, 2008 1 次提交
    • M
      kernel/cpu.c: create a CPU_STARTING cpu_chain notifier · e545a614
      Manfred Spraul 提交于
      Right now, there is no notifier that is called on a new cpu, before the new
      cpu begins processing interrupts/softirqs.
      Various kernel function would need that notification, e.g. kvm works around
      by calling smp_call_function_single(), rcu polls cpu_online_map.
      
      The patch adds a CPU_STARTING notification. It also adds a helper function
      that sends the message to all cpu_chain handlers.
      
      Tested on x86-64.
      All other archs are untested. Especially on sparc, I'm not sure if I got
      it right.
      Signed-off-by: NManfred Spraul <manfred@colorfullife.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      e545a614
  11. 26 7月, 2008 1 次提交
    • O
      workqueues: make get_online_cpus() useable for work->func() · 3da1c84c
      Oleg Nesterov 提交于
      workqueue_cpu_callback(CPU_DEAD) flushes cwq->thread under
      cpu_maps_update_begin().  This means that the multithreaded workqueues
      can't use get_online_cpus() due to the possible deadlock, very bad and
      very old problem.
      
      Introduce the new state, CPU_POST_DEAD, which is called after
      cpu_hotplug_done() but before cpu_maps_update_done().
      
      Change workqueue_cpu_callback() to use CPU_POST_DEAD instead of CPU_DEAD.
      This means that create/destroy functions can't rely on get_online_cpus()
      any longer and should take cpu_add_remove_lock instead.
      
      [akpm@linux-foundation.org: fix CONFIG_SMP=n]
      Signed-off-by: NOleg Nesterov <oleg@tv-sign.ru>
      Acked-by: NGautham R Shenoy <ego@in.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Max Krasnyansky <maxk@qualcomm.com>
      Cc: Paul Jackson <pj@sgi.com>
      Cc: Paul Menage <menage@google.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Vegard Nossum <vegard.nossum@gmail.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3da1c84c
  12. 29 4月, 2008 1 次提交
    • S
      cpu: fix section mismatch warnings in hotcpu_register · f718e318
      Sam Ravnborg 提交于
      Fix following warnings:
      WARNING: vmlinux.o(.data+0x5020): Section mismatch in reference from the variable cpu_vsyscall_notifier_nb.12876 to the function .cpuinit.text:cpu_vsyscall_notifier()
      WARNING: vmlinux.o(.data+0x9ce0): Section mismatch in reference from the variable profile_cpu_callback_nb.17654 to the function .devinit.text:profile_cpu_callback()
      WARNING: vmlinux.o(.data+0xd380): Section mismatch in reference from the variable workqueue_cpu_callback_nb.15004 to the function .devinit.text:workqueue_cpu_callback()
      WARNING: vmlinux.o(.data+0x11d00): Section mismatch in reference from the variable relay_hotcpu_callback_nb.19626 to the function .cpuinit.text:relay_hotcpu_callback()
      WARNING: vmlinux.o(.data+0x12970): Section mismatch in reference from the variable cpu_callback_nb.24694 to the function .devinit.text:cpu_callback()
      WARNING: vmlinux.o(.data+0x3fee0): Section mismatch in reference from the variable percpu_counter_hotcpu_callback_nb.10903 to the function .cpuinit.text:percpu_counter_hotcpu_callback()
      WARNING: vmlinux.o(.data+0x74ce0): Section mismatch in reference from the variable topology_cpu_callback_nb.12506 to the function .cpuinit.text:topology_cpu_callback()
      
      Functions used as argument are by definition only used in HOTPLUG_CPU
      situations so thay are annotated __cpuinit.  Annotate the static variable used
      by hotcpu_register with __cpuinitdata to match this definition.
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      Cc: Gautham R Shenoy <ego@in.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f718e318
  13. 19 4月, 2008 1 次提交
  14. 26 1月, 2008 3 次提交
  15. 07 1月, 2008 1 次提交
    • I
      CPU hotplug: fix cpu_is_offline() on !CONFIG_HOTPLUG_CPU · a263898f
      Ingo Molnar 提交于
      make randconfig bootup testing found that the cpufreq code
      crashes on bootup, if the powernow-k8 driver is enabled and
      if maxcpus=1 passed on the boot line to a !CONFIG_HOTPLUG_CPU
      kernel.
      
      First lockdep found out that there's an inconsistent unlock
      sequence:
      
       =====================================
       [ BUG: bad unlock balance detected! ]
       -------------------------------------
       swapper/1 is trying to release lock (&per_cpu(cpu_policy_rwsem, cpu)) at:
       [<ffffffff806ffd8e>] unlock_policy_rwsem_write+0x3c/0x42
       but there are no more locks to release!
      
      Call Trace:
       [<ffffffff806ffd8e>] unlock_policy_rwsem_write+0x3c/0x42
       [<ffffffff80251c29>] print_unlock_inbalance_bug+0x104/0x12c
       [<ffffffff80252f3a>] mark_held_locks+0x56/0x94
       [<ffffffff806ffd8e>] unlock_policy_rwsem_write+0x3c/0x42
       [<ffffffff807008b6>] cpufreq_add_dev+0x2a8/0x5c4
       ...
      
      then shortly afterwards the cpufreq code crashed on an assert:
      
       ------------[ cut here ]------------
       kernel BUG at drivers/cpufreq/cpufreq.c:1068!
       invalid opcode: 0000 [1] SMP
       [...]
       Call Trace:
        [<ffffffff805145d6>] sysdev_driver_unregister+0x5b/0x91
        [<ffffffff806ff520>] cpufreq_register_driver+0x15d/0x1a2
        [<ffffffff80cc0596>] powernowk8_init+0x86/0x94
       [...]
       ---[ end trace 1e9219be2b4431de ]---
      
      the bug was caused by maxcpus=1 bootup, which brought up the
      secondary core as !cpu_online() but !cpu_is_offline() either,
      which on on !CONFIG_HOTPLUG_CPU is always 0 (include/linux/cpu.h):
      
        /* CPUs don't go offline once they're online w/o CONFIG_HOTPLUG_CPU */
        static inline int cpu_is_offline(int cpu) { return 0; }
      
      but the cpufreq code uses cpu_online() and cpu_is_offline() in
      a mixed way - the low-level drivers use cpu_online(), while
      the cpufreq core uses cpu_is_offline(). This opened up the
      possibility to add the non-initialized sysdev device of the
      secondary core:
      
       cpufreq-core: trying to register driver powernow-k8
       cpufreq-core: adding CPU 0
       powernow-k8: BIOS error - no PSB or ACPI _PSS objects
       cpufreq-core: initialization failed
       cpufreq-core: adding CPU 1
       cpufreq-core: initialization failed
      
      which then blew up. The fix is to make cpu_is_offline() always
      the negation of cpu_online(). With that fix applied the kernel
      boots up fine without crashing:
      
       Calling initcall 0xffffffff80cc0510: powernowk8_init+0x0/0x94()
       powernow-k8: Found 1 AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ processors (1 cpu cores) (version 2.20.00)
       powernow-k8: BIOS error - no PSB or ACPI _PSS objects
       initcall 0xffffffff80cc0510: powernowk8_init+0x0/0x94() returned -19.
       initcall 0xffffffff80cc0510 ran for 19 msecs: powernowk8_init+0x0/0x94()
       Calling initcall 0xffffffff80cc328f: init_lapic_nmi_sysfs+0x0/0x39()
      
      We could fix this by making CPU enumeration aware of max_cpus, but that
      would be more fragile IMO, and the cpu_online(cpu) != cpu_is_offline(cpu)
      possibility was quite confusing and a continuous source of bugs too.
      
      Most distributions have kernels with CPU hotplug enabled, so this bug
      remained hidden for a long time.
      
      Bug forensics:
      
      The broken cpu_is_offline() API variant was introduced via:
      
       commit a59d2e4e6977e7b94e003c96a41f07e96cddc340
       Author: Rusty Russell <rusty@rustcorp.com.au>
       Date:   Mon Mar 8 06:06:03 2004 -0800
      
           [PATCH] minor cleanups for hotplug CPUs
      
      ( this predates linux-2.6.git, this commit is available from Thomas's
        historic git tree. )
      
      Then 1.5 years later the cpufreq code made use of it:
      
       commit c32b6b8e
       Author: Ashok Raj <ashok.raj@intel.com>
       Date:   Sun Oct 30 14:59:54 2005 -0800
      
           [PATCH] create and destroy cpufreq sysfs entries based on cpu notifiers
      
       +       if (cpu_is_offline(cpu))
       +               return 0;
      
      which is a correct use of the subtly broken new API. v2.6.15 then
      shipped with this bug included.
      
      then it took two more years for random-kernel qa to hit it.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a263898f
  16. 19 10月, 2007 1 次提交
  17. 31 8月, 2007 1 次提交
  18. 13 8月, 2007 1 次提交
  19. 17 7月, 2007 1 次提交
  20. 09 5月, 2007 1 次提交
  21. 03 4月, 2007 1 次提交
    • R
      [PATCH] Fix microcode-related suspend problem · 1d64b9cb
      Rafael J. Wysocki 提交于
      Fix the regression resulting from the recent change of suspend code
      ordering that causes systems based on Intel x86 CPUs using the microcode
      driver to hang during the resume.
      
      The problem occurs since the microcode driver uses request_firmware() in
      its CPU hotplug notifier, which is called after tasks has been frozen and
      hangs.  It can be fixed by telling the microcode driver to use the
      microcode stored in memory during the resume instead of trying to load it
      from disk.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Adrian Bunk <bunk@stusta.de>
      Cc: Tigran Aivazian <tigran@aivazian.fsnet.co.uk>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: Maxim <maximlevitsky@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1d64b9cb
  22. 13 2月, 2007 1 次提交
    • A
      [PATCH] hotplug: Allow modules to use the cpu hotplug notifiers even if !CONFIG_HOTPLUG_CPU · 47e627bc
      Avi Kivity 提交于
      The following patchset allows a host with running virtual machines to be
      suspended and, on at least a subset of the machines tested, resumed.  Note
      that this is orthogonal to suspending and resuming an individual guest to a
      file.
      
      A side effect of implementing suspend/resume is that cpu hotplug is now
      supported.  This should please the owners of big iron.
      
      This patch:
      
      KVM wants the cpu hotplug notifications, both for cpu hotplug itself, but more
      commonly for host suspend/resume.
      
      In order to avoid extensive #ifdefs, provide stubs when CONFIG_CPU_HOTPLUG is
      not defined.
      
      In all, we have four cases:
      
      - UP: register and unregister stubbed out
      - SMP+hotplug: full register and unregister
      - SMP, no hotplug, core: register as __init, unregister stubbed
            (cpus are brought up during core initialization)
      - SMP, no hotplug, module: register and unregister stubbed out
            (cpus cannot be brought up during module lifetime)
      Signed-off-by: NAvi Kivity <avi@qumranet.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Oleg Nesterov <oleg@tv-sign.ru>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      47e627bc
  23. 08 12月, 2006 2 次提交
  24. 07 12月, 2006 1 次提交
  25. 25 10月, 2006 1 次提交
  26. 26 9月, 2006 1 次提交
    • R
      [PATCH] Disable CPU hotplug during suspend · e3920fb4
      Rafael J. Wysocki 提交于
      The current suspend code has to be run on one CPU, so we use the CPU
      hotplug to take the non-boot CPUs offline on SMP machines.  However, we
      should also make sure that these CPUs will not be enabled by someone else
      after we have disabled them.
      
      The functions disable_nonboot_cpus() and enable_nonboot_cpus() are moved to
      kernel/cpu.c, because they now refer to some stuff in there that should
      better be static.  Also it's better if disable_nonboot_cpus() returns an
      error instead of panicking if something goes wrong, and
      enable_nonboot_cpus() has no reason to panic(), because the CPUs may have
      been enabled by the userland before it tries to take them online.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NPavel Machek <pavel@ucw.cz>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      e3920fb4
  27. 24 7月, 2006 1 次提交
    • L
      cpu hotplug: simplify and hopefully fix locking · aa953877
      Linus Torvalds 提交于
      The CPU hotplug locking was quite messy, with a recursive lock to
      handle the fact that both the actual up/down sequence wanted to
      protect itself from being re-entered, but the callbacks that it
      called also tended to want to protect themselves from CPU events.
      
      This splits the lock into two (one to serialize the whole hotplug
      sequence, the other to protect against the CPU present bitmaps
      changing). The latter still allows recursive usage because some
      subsystems (ondemand policy for cpufreq at least) had already gotten
      too used to the lax locking, but the locking mistakes are hopefully
      now less fundamental, and we now warn about recursive lock usage
      when we see it, in the hope that it can be fixed.
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      aa953877
  28. 02 7月, 2006 1 次提交
  29. 28 6月, 2006 3 次提交
    • C
      [PATCH] cpu hotplug: add hotplug versions of cpu_notifier · 39f4885c
      Chandra Seetharaman 提交于
      Define new macros register_hotcpu_notifier() and unregister_hotcpu_notifier()
      that redefines register_cpu_notifier() and unregister_cpu_notifier() for use
      only when HOTPLUG_CPU is defined.
      Signed-off-by: NChandra Seetharaman <sekharan@us.ibm.com>
      Cc: Ashok Raj <ashok.raj@intel.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      39f4885c
    • C
      [PATCH] cpu hotplug: make [un]register_cpu_notifier init time only · 65edc68c
      Chandra Seetharaman 提交于
      CPUs come online only at init time (unless CONFIG_HOTPLUG_CPU is defined).
      So, cpu_notifier functionality need to be available only at init time.
      
      This patch makes register_cpu_notifier() available only at init time, unless
      CONFIG_HOTPLUG_CPU is defined.
      
      This patch exports register_cpu_notifier() and unregister_cpu_notifier() only
      if CONFIG_HOTPLUG_CPU is defined.
      Signed-off-by: NChandra Seetharaman <sekharan@us.ibm.com>
      Cc: Ashok Raj <ashok.raj@intel.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      65edc68c
    • K
      [PATCH] node hotplug: register cpu: remove node struct · 76b67ed9
      KAMEZAWA Hiroyuki 提交于
      With Goto-san's patch, we can add new pgdat/node at runtime.  I'm now
      considering node-hot-add with cpu + memory on ACPI.
      
      I found acpi container, which describes node, could evaluate cpu before
      memory. This means cpu-hot-add occurs before memory hot add.
      
      In most part, cpu-hot-add doesn't depend on node hot add.  But register_cpu(),
      which creates symbolic link from node to cpu, requires that node should be
      onlined before register_cpu().  When a node is onlined, its pgdat should be
      there.
      
      This patch-set holds off creating symbolic link from node to cpu
      until node is onlined.
      
      This removes node arguments from register_cpu().
      
      Now, register_cpu() requires 'struct node' as its argument.  But the array of
      struct node is now unified in driver/base/node.c now (By Goto's node hotplug
      patch).  We can get struct node in generic way.  So, this argument is not
      necessary now.
      
      This patch also guarantees add cpu under node only when node is onlined.  It
      is necessary for node-hot-add vs.  cpu-hot-add patch following this.
      
      Moreover, register_cpu calculates cpu->node_id by cpu_to_node() without regard
      to its 'struct node *root' argument.  This patch removes it.
      
      Also modify callers of register_cpu()/unregister_cpu, whose args are changed
      by register-cpu-remove-node-struct patch.
      
      [Brice.Goglin@ens-lyon.org: fix it]
      Signed-off-by: NKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Yasunori Goto <y-goto@jp.fujitsu.com>
      Cc: Ashok Raj <ashok.raj@intel.com>
      Cc: Dave Hansen <haveblue@us.ibm.com>
      Signed-off-by: NBrice Goglin <Brice.Goglin@ens-lyon.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      76b67ed9
  30. 26 3月, 2006 1 次提交
  31. 21 3月, 2006 1 次提交
  32. 29 11月, 2005 1 次提交
    • A
      [PATCH] clean up lock_cpu_hotplug() in cpufreq · a9d9baa1
      Ashok Raj 提交于
      There are some callers in cpufreq hotplug notify path that the lowest
      function calls lock_cpu_hotplug().  The lock is already held during
      cpu_up() and cpu_down() calls when the notify calls are broadcast to
      registered clients.
      
      Ideally if possible, we could disable_preempt() at the highest caller and
      make sure we dont sleep in the path down in cpufreq->driver_target() calls
      but the calls are so intertwined and cumbersome to cleanup.
      
      Hence we consistently use lock_cpu_hotplug() and unlock_cpu_hotplug() in
      all places.
      
       - Removed export of cpucontrol semaphore and made it static.
       - removed explicit uses of up/down with lock_cpu_hotplug()
         so we can keep track of the the callers in same thread context and
         just keep refcounts without calling a down() that causes a deadlock.
       - Removed current_in_hotplug() uses
       - Removed PF_HOTPLUG_CPU in sched.h introduced for the current_in_hotplug()
         temporary workaround.
      
      Tested with insmod of cpufreq_stat.ko, and logical online/offline
      to make sure we dont have any hang situations.
      Signed-off-by: NAshok Raj <ashok.raj@intel.com>
      Cc: Zwane Mwaikambo <zwane@linuxpower.ca>
      Cc: Shaohua Li <shaohua.li@intel.com>
      Cc: "Siddha, Suresh B" <suresh.b.siddha@intel.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      a9d9baa1
  33. 09 11月, 2005 1 次提交
    • A
      [PATCH] cpu hotplug: fix locking in cpufreq drivers · 90d45d17
      Ashok Raj 提交于
      When calling target drivers to set frequency, we take cpucontrol lock.
      When we modified the code to accomodate CPU hotplug, there was an attempt
      to take a double lock of cpucontrol leading to a deadlock.  Since the
      current thread context is already holding the cpucontrol lock, we dont need
      to make another attempt to acquire it.
      
      Now we leave a trace in current->flags indicating current thread already is
      under cpucontrol lock held, so we dont attempt to do this another time.
      
      Thanks to Andrew Morton for the beating:-)
      
      From: Brice Goglin <Brice.Goglin@ens-lyon.org>
      
        Build fix
      
      (akpm: this patch is still unpleasant.  Ashok continues to look for a cleaner
      solution, doesn't he?  ;))
      Signed-off-by: NAshok Raj <ashok.raj@intel.com>
      Signed-off-by: NBrice Goglin <Brice.Goglin@ens-lyon.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      90d45d17