1. 19 10月, 2007 1 次提交
    • N
      bitops: introduce lock ops · 26333576
      Nick Piggin 提交于
      Introduce test_and_set_bit_lock / clear_bit_unlock bitops with lock semantics.
      Convert all architectures to use the generic implementation.
      Signed-off-by: NNick Piggin <npiggin@suse.de>
      Acked-By: NDavid Howells <dhowells@redhat.com>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
      Cc: Bryan Wu <bryan.wu@analog.com>
      Cc: Mikael Starvik <starvik@axis.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: Hirokazu Takata <takata@linux-m32r.org>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Roman Zippel <zippel@linux-m68k.org>
      Cc: Greg Ungerer <gerg@uclinux.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Kyle McMartin <kyle@mcmartin.ca>
      Cc: Matthew Wilcox <willy@debian.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: Kazumoto Kojima <kkojima@rr.iij4u.or.jp>
      Cc: Richard Curnow <rc@rc0.org.uk>
      Cc: William Lee Irwin III <wli@holomorphy.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
      Cc: Miles Bader <uclinux-v850@lsi.nec.co.jp>
      Cc: Andi Kleen <ak@muc.de>
      Cc: Chris Zankel <chris@zankel.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      26333576
  2. 18 10月, 2007 1 次提交
    • C
      x86: Eliminate result signage problem in asm-x86_64/bitops.h · d2ccc3fd
      Chuck Lever 提交于
      The return type of __scanbit() doesn't match the return type of
      find_{first,next}_bit().  Thus when you construct something like
      this:
      
         boolean ? __scanbit() : find_first_bit()
      
      you get an unsigned long result if "boolean" is true, and a signed
      long result if "boolean" is false.
      
      In file included from /home/cel/src/linux/include/linux/mmzone.h:15,
                       from /home/cel/src/linux/include/linux/gfp.h:4,
                       from /home/cel/src/linux/include/linux/slab.h:14,
                       from /home/cel/src/linux/include/linux/percpu.h:5,
                       from
      /home/cel/src/linux/include/linux/rcupdate.h:41,
                       from /home/cel/src/linux/include/linux/dcache.h:10,
                       from /home/cel/src/linux/include/linux/fs.h:275,
                       from /home/cel/src/linux/fs/nfs/sysctl.c:9:
      /home/cel/src/linux/include/linux/nodemask.h: In function
      ‘__first_node’:
      /home/cel/src/linux/include/linux/nodemask.h:229: warning: signed and
      unsigned type in conditional expression
      /home/cel/src/linux/include/linux/nodemask.h: In function
      ‘__next_node’:
      /home/cel/src/linux/include/linux/nodemask.h:235: warning: signed and
      unsigned type in conditional expression
      /home/cel/src/linux/include/linux/nodemask.h: In function
      ‘__first_unset_node’:
      /home/cel/src/linux/include/linux/nodemask.h:253: warning: signed and
      unsigned type in conditional expression
      
      [ tglx: arch/x86 adaptation ]
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      d2ccc3fd
  3. 11 10月, 2007 1 次提交
  4. 13 2月, 2007 1 次提交
  5. 11 1月, 2007 1 次提交
  6. 26 9月, 2006 1 次提交
    • A
      [PATCH] optimize hweight64 for x86_64 · 0136611c
      Andi Kleen 提交于
      Based on patch from David Rientjes <rientjes@google.com>, but
      changed by AK.
      
      Optimizes the 64-bit hamming weight for x86_64 processors assuming they
      have fast multiplication.  Uses five fewer bitops than the generic
      hweight64.  Benchmark on one EMT64 showed ~25% speedup with 2^24
      consecutive calls.
      
      Define a new ARCH_HAS_FAST_MULTIPLIER that can be set by other
      architectures that can also multiply fast.
      Signed-off-by: NAndi Kleen <ak@suse.de>
      0136611c
  7. 27 6月, 2006 1 次提交
    • G
      [PATCH] x86_64: x86_64 version of the smp alternative patch. · d167a518
      Gerd Hoffmann 提交于
      Changes are largely identical to the i386 version:
      
       * alternative #define are moved to the new alternative.h file.
       * one new elf section with pointers to the lock prefixes which can be
         nop'ed out for non-smp.
       * two new elf sections simliar to the "classic" alternatives to
         replace SMP code with simpler UP code.
       * fixup headers to use alternative.h instead of defining their own
         LOCK / LOCK_PREFIX macros.
      
      The patch reuses the i386 version of the alternatives code to avoid code
      duplication.  The code in alternatives.c was shuffled around a bit to
      reduce the number of #ifdefs needed.  It also got some tweaks needed for
      x86_64 (vsyscall page handling) and new features (noreplacement option
      which was x86_64 only up to now).  Debug printk's are changed from
      compile-time to runtime.
      
      Loosely based on a early version from Bastian Blank <waldi@debian.org>
      Signed-off-by: NGerd Hoffmann <kraxel@suse.de>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      d167a518
  8. 26 4月, 2006 1 次提交
  9. 27 3月, 2006 1 次提交
  10. 12 1月, 2006 2 次提交
  11. 04 1月, 2006 2 次提交
  12. 29 7月, 2005 1 次提交
  13. 24 6月, 2005 1 次提交
  14. 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