An error occurred fetching the project authors.
  1. 08 Dec, 2006 2 commits
    • David Howells's avatar
      [PATCH] LOG2: Implement a general integer log2 facility in the kernel · f0d1b0b3
      David Howells authored
      This facility provides three entry points:
      
      	ilog2()		Log base 2 of unsigned long
      	ilog2_u32()	Log base 2 of u32
      	ilog2_u64()	Log base 2 of u64
      
      These facilities can either be used inside functions on dynamic data:
      
      	int do_something(long q)
      	{
      		...;
      		y = ilog2(x)
      		...;
      	}
      
      Or can be used to statically initialise global variables with constant values:
      
      	unsigned n = ilog2(27);
      
      When performing static initialisation, the compiler will report "error:
      initializer element is not constant" if asked to take a log of zero or of
      something not reducible to a constant.  They treat negative numbers as
      unsigned.
      
      When not dealing with a constant, they fall back to using fls() which permits
      them to use arch-specific log calculation instructions - such as BSR on
      x86/x86_64 or SCAN on FRV - if available.
      
      [akpm@osdl.org: MMC fix]
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Wojtek Kaniewski <wojtekka@toxygen.net>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      f0d1b0b3
    • Jeremy Fitzhardinge's avatar
      [PATCH] Generic BUG for x86-64 · c31a0bf3
      Jeremy Fitzhardinge authored
      This makes x86-64 use the generic BUG machinery.
      
      The main advantage in using the generic BUG machinery for x86-64 is that
      the inlined overhead of BUG is just the ud2a instruction; the file+line
      information are no longer inlined into the instruction stream.  This
      reduces cache pollution.
      Signed-off-by: default avatarJeremy Fitzhardinge <jeremy@goop.org>
      Cc: Andi Kleen <ak@muc.de>
      Cc: Hugh Dickens <hugh@veritas.com>
      Cc: Michael Ellerman <michael@ellerman.id.au>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      c31a0bf3
  2. 07 Dec, 2006 3 commits
  3. 03 Oct, 2006 1 commit
  4. 02 Oct, 2006 1 commit
    • Ananth N Mavinakayanahalli's avatar
      [PATCH] Kprobes: Make kprobe modules more portable · 3a872d89
      Ananth N Mavinakayanahalli authored
      In an effort to make kprobe modules more portable, here is a patch that:
      
      o Introduces the "symbol_name" field to struct kprobe.
        The symbol->address resolution now happens in the kernel in an
        architecture agnostic manner. 64-bit powerpc users no longer have
        to specify the ".symbols"
      o Introduces the "offset" field to struct kprobe to allow a user to
        specify an offset into a symbol.
      o The legacy mechanism of specifying the kprobe.addr is still supported.
        However, if both the kprobe.addr and kprobe.symbol_name are specified,
        probe registration fails with an -EINVAL.
      o The symbol resolution code uses kallsyms_lookup_name(). So
        CONFIG_KPROBES now depends on CONFIG_KALLSYMS
      o Apparantly kprobe modules were the only legitimate out-of-tree user of
        the kallsyms_lookup_name() EXPORT. Now that the symbol resolution
        happens in-kernel, remove the EXPORT as suggested by Christoph Hellwig
      o Modify tcp_probe.c that uses the kprobe interface so as to make it
        work on multiple platforms (in its earlier form, the code wouldn't
        work, say, on powerpc)
      Signed-off-by: default avatarAnanth N Mavinakayanahalli <ananth@in.ibm.com>
      Signed-off-by: default avatarPrasanna S Panchamukhi <prasanna@in.ibm.com>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      3a872d89
  5. 01 Oct, 2006 1 commit
  6. 27 Sep, 2006 3 commits
  7. 26 Sep, 2006 6 commits
  8. 12 Sep, 2006 1 commit
  9. 03 Jul, 2006 2 commits
  10. 29 Jun, 2006 2 commits
  11. 26 Jun, 2006 3 commits
    • Jon Mason's avatar
      [PATCH] x86_64: Calgary IOMMU - Calgary specific bits · e465058d
      Jon Mason authored
      This patch hooks Calgary into the build, the x86-64 IOMMU
      initialization paths, and introduces the Calgary specific bits.  The
      implementation draws inspiration from both PPC (which has support for
      the same chip but requires firmware support which we don't have on
      x86-64) and gart. Calgary is different from gart in that it support a
      translation table per PHB, as opposed to the single gart aperture.
      
      Changes from previous version:
       * Addition of boot-time disablement for bus-level translation/isolation
         (e.g, enable userspace DMA for things like X)
       * Usage of newer IOMMU abstraction functions
      Signed-off-by: default avatarMuli Ben-Yehuda <muli@il.ibm.com>
      Signed-off-by: default avatarJon Mason <jdmason@us.ibm.com>
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      e465058d
    • Andi Kleen's avatar
      [PATCH] x86_64: Rename IOMMU option, fix help and mark option embedded. · a813ce43
      Andi Kleen authored
       - Rename the GART_IOMMU option to IOMMU to make clear it's not
         just for AMD
       - Rewrite the help text to better emphatise this fact
       - Make it an embedded option because too many people get it wrong.
      
      To my astonishment I discovered the aacraid driver tests this
      symbol directly. This looks quite broken to me - it's an internal
      implementation detail of the PCI DMA API. Can the maintainer
      please clarify what this test was intended to do?
      
      Cc: linux-scsi@vger.kernel.org
      Cc: alan@redhat.com
      Cc: markh@osdl.org
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      a813ce43
    • Andi Kleen's avatar
      [PATCH] x86_64: Clean and enhance up K8 northbridge access code · a32073bf
      Andi Kleen authored
       - Factor out the duplicated access/cache code into a single file
         * Shared between i386/x86-64.
       - Share flush code between AGP and IOMMU
         * Fix a bug: AGP didn't wait for end of flush before
       - Drop 8 northbridges limit and allocate dynamically
       - Add lock to serialize AGP and IOMMU GART flushes
       - Add PCI ID for next AMD northbridge
       - Random related cleanups
      
      The old K8 NUMA discovery code is unchanged. New systems
      should all use SRAT for this.
      
      Cc: "Navin Boppuri" <navin.boppuri@newisys.com>
      Cc: Dave Jones <davej@redhat.com>
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      a32073bf
  12. 22 Jun, 2006 1 commit
  13. 11 Apr, 2006 1 commit
    • Yasunori Goto's avatar
      [PATCH] Configurable NODES_SHIFT · c80d79d7
      Yasunori Goto authored
      Current implementations define NODES_SHIFT in include/asm-xxx/numnodes.h for
      each arch.  Its definition is sometimes configurable.  Indeed, ia64 defines 5
      NODES_SHIFT values in the current git tree.  But it looks a bit messy.
      
      SGI-SN2(ia64) system requires 1024 nodes, and the number of nodes already has
      been changeable by config.  Suitable node's number may be changed in the
      future even if it is other architecture.  So, I wrote configurable node's
      number.
      
      This patch set defines just default value for each arch which needs multi
      nodes except ia64.  But, it is easy to change to configurable if necessary.
      
      On ia64 the number of nodes can be already configured in generic ia64 and SN2
      config.  But, NODES_SHIFT is defined for DIG64 and HP'S machine too.  So, I
      changed it so that all platforms can be configured via CONFIG_NODES_SHIFT.  It
      would be simpler.
      
      See also: http://marc.theaimsgroup.com/?l=linux-kernel&m=114358010523896&w=2Signed-off-by: default avatarYasunori Goto <y-goto@jp.fujitsu.com>
      Cc: Hirokazu Takata <takata@linux-m32r.org>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: Andi Kleen <ak@muc.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Kyle McMartin <kyle@mcmartin.ca>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Jack Steiner <steiner@sgi.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      c80d79d7
  14. 09 Apr, 2006 1 commit
  15. 02 Apr, 2006 1 commit
  16. 27 Mar, 2006 2 commits
  17. 26 Mar, 2006 1 commit
  18. 25 Mar, 2006 5 commits
    • Jon Mason's avatar
      [PATCH] x86_64: Make GART_IOMMU kconfig help text more specific (trivial) · 5d05f4de
      Jon Mason authored
      Have the GART_IOMMU help text specify that this is the hardware IOMMU in
      amd64 processors.  This will be significant if/when other IOMMUs are
      added to the x86-64 architecture. :-)
      
      Also, note that the previous help text stated that IOMMU was needed for
      >3GB memory instead of >4GB.  This is fixed in the newer version.
      Signed-off-by: default avatarJon Mason <jdmason@us.ibm.com>
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      5d05f4de
    • Andi Kleen's avatar
      [PATCH] x86_64: Remove CONFIG_UNORDERED_IO · ba22f135
      Andi Kleen authored
      It was a failed experiment - all benchmarks done with it on both AMD
      and Intel showed it was a loss. That was probably because the store
      buffers of the CPUs for write combining traffic weren't large enough.
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      ba22f135
    • Andi Kleen's avatar
      [PATCH] x86_64: Limit max number of CPUs to 255 · 01d4bed4
      Andi Kleen authored
      Because 256 causes overflows in some code that stores them in 8 bit
      fields and the x86 APIC architecture cannot handle more than 255
      anyways.
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      01d4bed4
    • Arjan van de Ven's avatar
      [PATCH] x86_64: Basic reorder infrastructure · 4bdc3b7f
      Arjan van de Ven authored
      This patch puts the infrastructure in place to allow for a reordering of
      functions based inside the vmlinux. The general idea is that it is possible
      to put all "common" functions into the first 2Mb of the code, so that they
      are covered by one TLB entry. This as opposed to the current situation where
      a typical vmlinux covers about 3.5Mb (on x86-64) and thus 2 TLB entries.
      
      This is done by enabling the -ffunction-sections flag in gcc, which puts
      each function in its own ELF section, so that the linker can then order them
      in a way defined by the linker script.
      
      As per previous discussions, Linus said he wanted a "static" list for this,
      eg a list provided by the kernel tarbal, so that most people have the same
      ordering at least. A script is provided to create this list based on
      readprofile(1) output. The included list is provisional, and entirely biased
      on my own testbox and me running a few kernel compiles and some other
      things.
      
      I think that to get to a better list we need to invite people to submit
      their own profiles, and somehow add those all up and base the final list on
      that. I'm willing to do that effort if this is ends up being the prefered
      approach. Such an effort probably needs to be repeated like once a year or
      so to adopt to the changing nature of the kernel.
      
      Made it a CONFIG with default n because it increases link times
      dramatically.
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      4bdc3b7f
    • Andi Kleen's avatar
      [PATCH] x86_64: Move kernel to 2MB · 04103609
      Andi Kleen authored
      As suggested by Andi (and Alan), move the default kernel location
      from 1Mb to 2Mb, to align to the start of a TLB entry.
      Signed-off-by: default avatarArjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      04103609
  19. 27 Feb, 2006 1 commit
  20. 26 Feb, 2006 1 commit
  21. 17 Jan, 2006 1 commit