1. 31 10月, 2005 1 次提交
    • A
      [PATCH] create and destroy cpufreq sysfs entries based on cpu notifiers · c32b6b8e
      Ashok Raj 提交于
      cpufreq entries in sysfs should only be populated when CPU is online state.
       When we either boot with maxcpus=x and then boot the other cpus by echoing
      to sysfs online file, these entries should be created and destroyed when
      CPU_DEAD is notified.  Same treatement as cache entries under sysfs.
      
      We place the processor in the lowest frequency, so hw managed P-State
      transitions can still work on the other threads to save power.
      
      Primary goal was to just make these directories appear/disapper dynamically.
      
      There is one in this patch i had to do, which i really dont like myself but
      probably best if someone handling the cpufreq infrastructure could give
      this code right treatment if this is not acceptable.  I guess its probably
      good for the first cut.
      
      - Converting lock_cpu_hotplug()/unlock_cpu_hotplug() to disable/enable preempt.
        The locking was smack in the middle of the notification path, when the
        hotplug is already holding the lock. I tried another solution to avoid this
        so avoid taking locks if we know we are from notification path. The solution
        was getting very ugly and i decided this was probably good for this iteration
        until someone who understands cpufreq could do a better job than me.
      
      (akpm: export cpucontrol to GPL modules: drivers/cpufreq/cpufreq_stats.c now
      does lock_cpu_hotplug())
      Signed-off-by: NAshok Raj <ashok.raj@intel.com>
      Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Cc: Dave Jones <davej@codemonkey.org.uk>
      Cc: Zwane Mwaikambo <zwane@holomorphy.com>
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c32b6b8e
  2. 26 6月, 2005 1 次提交
    • Z
      [PATCH] i386 CPU hotplug · f3705136
      Zwane Mwaikambo 提交于
      (The i386 CPU hotplug patch provides infrastructure for some work which Pavel
      is doing as well as for ACPI S3 (suspend-to-RAM) work which Li Shaohua
      <shaohua.li@intel.com> is doing)
      
      The following provides i386 architecture support for safely unregistering and
      registering processors during runtime, updated for the current -mm tree.  In
      order to avoid dumping cpu hotplug code into kernel/irq/* i dropped the
      cpu_online check in do_IRQ() by modifying fixup_irqs().  The difference being
      that on cpu offline, fixup_irqs() is called before we clear the cpu from
      cpu_online_map and a long delay in order to ensure that we never have any
      queued external interrupts on the APICs.  There are additional changes to s390
      and ppc64 to account for this change.
      
      1) Add CONFIG_HOTPLUG_CPU
      2) disable local APIC timer on dead cpus.
      3) Disable preempt around irq balancing to prevent CPUs going down.
      4) Print irq stats for all possible cpus.
      5) Debugging check for interrupts on offline cpus.
      6) Hacky fixup_irqs() to redirect irqs when cpus go off/online.
      7) play_dead() for offline cpus to spin inside.
      8) Handle offline cpus set in flush_tlb_others().
      9) Grab lock earlier in smp_call_function() to prevent CPUs going down.
      10) Implement __cpu_disable() and __cpu_die().
      11) Enable local interrupts in cpu_enable() after fixup_irqs()
      12) Don't fiddle with NMI on dead cpu, but leave intact on other cpus.
      13) Program IRQ affinity whilst cpu is still in cpu_online_map on offline.
      Signed-off-by: NZwane Mwaikambo <zwane@linuxpower.ca>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      f3705136
  3. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4