1. 12 Jan, 2006 1 commit
  2. 15 Nov, 2005 2 commits
    • Andi Kleen's avatar
      [PATCH] x86_64: New heuristics to find out hotpluggable CPUs. · 420f8f68
      Andi Kleen authored
      
      
      With a NR_CPUS==128 kernel with CPU hotplug enabled we would waste 4MB
      on per CPU data of all possible CPUs.  The reason was that HOTPLUG
      always set up possible map to NR_CPUS cpus and then we need to allocate
      that much (each per CPU data is roughly ~32k now)
      
      The underlying problem is that ACPI didn't tell us how many hotplug CPUs
      the platform supports.  So the old code just assumed all, which would
      lead to this memory wastage.
      
      This implements some new heuristics:
      
       - If the BIOS specified disabled CPUs in the ACPI/mptables assume they
         can be enabled later (this is bending the ACPI specification a bit,
         but seems like a obvious extension)
       - The user can overwrite it with a new additionals_cpus=NUM option
       - Otherwise use half of the available CPUs or 2, whatever is more.
      
      Cc: ashok.raj@intel.com
      Cc: len.brown@intel.com
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      420f8f68
    • Siddha, Suresh B's avatar
      [PATCH] x86_64: Unmap NULL during early bootup · f6c2e333
      Siddha, Suresh B authored
      
      
      We should zap the low mappings, as soon as possible, so that we can catch
      kernel bugs more effectively. Previously early boot had NULL mapped
      and didn't trap on NULL references.
      
      This patch introduces boot_level4_pgt, which will always have low identity
      addresses mapped.  Druing boot, all the processors will use this as their
      level4 pgt.  On BP, we will switch to init_level4_pgt as soon as we enter C
      code and zap the low mappings as soon as we are done with the usage of
      identity low mapped addresses.  On AP's we will zap the low mappings as
      soon as we jump to C code.
      Signed-off-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: default avatarAshok Raj <ashok.raj@intel.com>
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      f6c2e333
  3. 11 Nov, 2005 1 commit
    • Ashok Raj's avatar
      [PATCH] PCI: Change MSI to use physical delivery mode always · b4033c17
      Ashok Raj authored
      
      
      MSI hardcoded delivery mode to use logical delivery mode. Recently
      x86_64 moved to use physical mode addressing to support physflat mode.
      With this mode enabled noticed that my eth with MSI werent working.
      
      msi_address_init()  was hardcoded to use logical mode for i386 and x86_64.
      So when we switch to use physical mode, things stopped working.
      
      Since anyway we dont use lowest priority delivery with MSI, its always
      directed to just a single CPU. Its safe  and simpler to use
      physical mode always, even when we use logical delivery mode for IPI's
      or other ioapic RTE's.
      Signed-off-by: default avatarAshok Raj <ashok.raj@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      b4033c17
  4. 10 Oct, 2005 1 commit
  5. 12 Sep, 2005 1 commit
  6. 29 Jul, 2005 2 commits
  7. 25 Jun, 2005 2 commits
  8. 22 Jun, 2005 1 commit
    • Ingo Molnar's avatar
      [PATCH] smp_processor_id() cleanup · 39c715b7
      Ingo Molnar authored
      
      
      This patch implements a number of smp_processor_id() cleanup ideas that
      Arjan van de Ven and I came up with.
      
      The previous __smp_processor_id/_smp_processor_id/smp_processor_id API
      spaghetti was hard to follow both on the implementational and on the
      usage side.
      
      Some of the complexity arose from picking wrong names, some of the
      complexity comes from the fact that not all architectures defined
      __smp_processor_id.
      
      In the new code, there are two externally visible symbols:
      
       - smp_processor_id(): debug variant.
      
       - raw_smp_processor_id(): nondebug variant. Replaces all existing
         uses of _smp_processor_id() and __smp_processor_id(). Defined
         by every SMP architecture in include/asm-*/smp.h.
      
      There is one new internal symbol, dependent on DEBUG_PREEMPT:
      
       - debug_smp_processor_id(): internal debug variant, mapped to
                                   smp_processor_id().
      
      Also, i moved debug_smp_processor_id() from lib/kernel_lock.c into a new
      lib/smp_processor_id.c file.  All related comments got updated and/or
      clarified.
      
      I have build/boot tested the following 8 .config combinations on x86:
      
       {SMP,UP} x {PREEMPT,!PREEMPT} x {DEBUG_PREEMPT,!DEBUG_PREEMPT}
      
      I have also build/boot tested x64 on UP/PREEMPT/DEBUG_PREEMPT.  (Other
      architectures are untested, but should work just fine.)
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarArjan van de Ven <arjan@infradead.org>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      39c715b7
  9. 16 Apr, 2005 3 commits
    • Andi Kleen's avatar
      [PATCH] x86_64: Switch SMP bootup over to new CPU hotplug state machine · a8ab26fe
      Andi Kleen authored
      
      
      This will allow hotplug CPU in the future and in general cleans up a lot of
      crufty code.  It also should plug some races that the old hackish way
      introduces.  Remove one old race workaround in NMI watchdog setup that is not
      needed anymore.
      
      I removed the old total sum of bogomips reporting code.  The brag value of
      BogoMips has been greatly devalued in the last years on the open market.
      
      Real CPU hotplug will need some more work, but the infrastructure for it is
      there now.
      
      One drawback: the new TSC sync algorithm is less accurate than before.  The
      old way of zeroing TSCs is too intrusive to do later.  Instead the TSC of the
      BP is duplicated now, which is less accurate.
      
      akpm:
      
      - sync_tsc_bp_init seems to have the sense of `init' inverted.
      
      - SPIN_LOCK_UNLOCKED is deprecated - use DEFINE_SPINLOCK.
      
      Cc: <rusty@rustcorp.com.au>
      Cc: <mingo@elte.hu>
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      a8ab26fe
    • Andi Kleen's avatar
      [PATCH] x86_64: add support for Intel dual-core detection and displaying · 3dd9d514
      Andi Kleen authored
      Appended patch adds the support for Intel dual-core detection and displaying
      the core related information in /proc/cpuinfo.  
      
      It adds two new fields "core id" and "cpu cores" to x86 /proc/cpuinfo and the
      "core id" field for x86_64("cpu cores" field is already present in x86_64).
      
      Number of processor cores in a die is detected using cpuid(4) and this is
      documented in IA-32 Intel Architecture Software Developer's Manual (vol 2a)
      (http://developer.intel.com/design/pentium4/manuals/index_new.htm#sdm_vol2a
      
      )
      
      This patch also adds cpu_core_map similar to cpu_sibling_map.
      
      Slightly hacked by AK.
      Signed-off-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      3dd9d514
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      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