1. 29 7月, 2006 3 次提交
  2. 26 7月, 2006 1 次提交
    • A
      [PATCH] Reorganize the cpufreq cpu hotplug locking to not be totally bizare · 153d7f3f
      Arjan van de Ven 提交于
      The patch below moves the cpu hotplugging higher up in the cpufreq
      layering; this is needed to avoid recursive taking of the cpu hotplug
      lock and to otherwise detangle the mess.
      
      The new rules are:
      1. you must do lock_cpu_hotplug() around the following functions:
         __cpufreq_driver_target
         __cpufreq_governor (for CPUFREQ_GOV_LIMITS operation only)
         __cpufreq_set_policy
      2. governer methods (.governer) must NOT take the lock_cpu_hotplug()
         lock in any way; they are called with the lock taken already
      3. if your governer spawns a thread that does things, like calling
         __cpufreq_driver_target, your thread must honor rule #1.
      4. the policy lock and other cpufreq internal locks nest within
         the lock_cpu_hotplug() lock.
      
      I'm not entirely happy about how the __cpufreq_governor rule ended up
      (conditional locking rule depending on the argument) but basically all
      callers pass this as a constant so it's not too horrible.
      
      The patch also removes the cpufreq_governor() function since during the
      locking audit it turned out to be entirely unused (so no need to fix it)
      
      The patch works on my testbox, but it could use more testing
      (otoh... it can't be much worse than the current code)
      Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      153d7f3f
  3. 25 7月, 2006 6 次提交
  4. 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
  5. 22 7月, 2006 6 次提交
  6. 17 7月, 2006 2 次提交
  7. 15 7月, 2006 21 次提交