27 May, 2011

2 commits

  • By the previous style change, CONFIG_GENERIC_FIND_NEXT_BIT,
    CONFIG_GENERIC_FIND_BIT_LE, and CONFIG_GENERIC_FIND_LAST_BIT are not used
    to test for existence of find bitops anymore.

    Signed-off-by: Akinobu Mita
    Acked-by: Greg Ungerer
    Cc: Arnd Bergmann
    Cc: Russell King
    Cc: Martin Schwidefsky
    Cc: Heiko Carstens
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Akinobu Mita
     
  • The style that we normally use in asm-generic is to test the macro itself
    for existence, so in asm-generic, do:

    #ifndef find_next_zero_bit_le
    extern unsigned long find_next_zero_bit_le(const void *addr,
    unsigned long size, unsigned long offset);
    #endif

    and in the architectures, write

    static inline unsigned long find_next_zero_bit_le(const void *addr,
    unsigned long size, unsigned long offset)
    #define find_next_zero_bit_le find_next_zero_bit_le

    This adds the #ifndef for each of the find bitops in the generic header
    and source files.

    Suggested-by: Arnd Bergmann
    Signed-off-by: Akinobu Mita
    Acked-by: Russell King
    Cc: Martin Schwidefsky
    Cc: Heiko Carstens
    Cc: Greg Ungerer
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Akinobu Mita
     

24 Mar, 2011

3 commits

  • This introduces CONFIG_GENERIC_FIND_BIT_LE to tell whether to use generic
    implementation of find_*_bit_le() in lib/find_next_bit.c or not.

    For now we select CONFIG_GENERIC_FIND_BIT_LE for all architectures which
    enable CONFIG_GENERIC_FIND_NEXT_BIT.

    But m68knommu wants to define own faster find_next_zero_bit_le() and
    continues using generic find_next_{,zero_}bit().
    (CONFIG_GENERIC_FIND_NEXT_BIT and !CONFIG_GENERIC_FIND_BIT_LE)

    Signed-off-by: Akinobu Mita
    Cc: Greg Ungerer
    Cc: Arnd Bergmann
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Akinobu Mita
     
  • This makes the little-endian bitops take any pointer types by changing the
    prototypes and adding casts in the preprocessor macros.

    That would seem to at least make all the filesystem code happier, and they
    can continue to do just something like

    #define ext2_set_bit __test_and_set_bit_le

    (or whatever the exact sequence ends up being).

    Signed-off-by: Akinobu Mita
    Cc: Arnd Bergmann
    Cc: Richard Henderson
    Cc: Ivan Kokshaysky
    Cc: Mikael Starvik
    Cc: David Howells
    Cc: Yoshinori Sato
    Cc: "Luck, Tony"
    Cc: Ralf Baechle
    Cc: Kyle McMartin
    Cc: Matthew Wilcox
    Cc: Grant Grundler
    Cc: Paul Mundt
    Cc: Kazumoto Kojima
    Cc: Hirokazu Takata
    Cc: "David S. Miller"
    Cc: Chris Zankel
    Cc: Ingo Molnar
    Cc: Thomas Gleixner
    Cc: Hans-Christian Egtvedt
    Cc: "H. Peter Anvin"
    Cc: Benjamin Herrenschmidt
    Cc: Paul Mackerras
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Akinobu Mita
     
  • As a preparation for providing little-endian bitops for all architectures,
    This renames generic implementation of little-endian bitops. (remove
    "generic_" prefix and postfix "_le")

    s/generic_find_next_le_bit/find_next_bit_le/
    s/generic_find_next_zero_le_bit/find_next_zero_bit_le/
    s/generic_find_first_zero_le_bit/find_first_zero_bit_le/
    s/generic___test_and_set_le_bit/__test_and_set_bit_le/
    s/generic___test_and_clear_le_bit/__test_and_clear_bit_le/
    s/generic_test_le_bit/test_bit_le/
    s/generic___set_le_bit/__set_bit_le/
    s/generic___clear_le_bit/__clear_bit_le/
    s/generic_test_and_set_le_bit/test_and_set_bit_le/
    s/generic_test_and_clear_le_bit/test_and_clear_bit_le/

    Signed-off-by: Akinobu Mita
    Acked-by: Arnd Bergmann
    Acked-by: Hans-Christian Egtvedt
    Cc: Geert Uytterhoeven
    Cc: Roman Zippel
    Cc: Andreas Schwab
    Cc: Greg Ungerer
    Cc: Benjamin Herrenschmidt
    Cc: Paul Mackerras
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Akinobu Mita
     

29 Apr, 2008

1 commit

  • The mapsize optimizations which were moved from x86 to the generic
    code in commit 64970b68d2b3ed32b964b0b30b1b98518fde388e increased the
    binary size on non x86 architectures.

    Looking into the real effects of the "optimizations" it turned out
    that they are not used in find_next_bit() and find_next_zero_bit().

    The ones in find_first_bit() and find_first_zero_bit() are used in a
    couple of places but none of them is a real hot path.

    Remove the "optimizations" all together and call the library functions
    unconditionally.

    Boot-tested on x86 and compile tested on every cross compiler I have.

    Signed-off-by: Thomas Gleixner
    Signed-off-by: Linus Torvalds

    Thomas Gleixner
     

27 Apr, 2008

3 commits

  • Generic versions of __find_first_bit and __find_first_zero_bit
    are introduced as simplified versions of __find_next_bit and
    __find_next_zero_bit. Their compilation and use are guarded by
    a new config variable GENERIC_FIND_FIRST_BIT.

    The generic versions of find_first_bit and find_first_zero_bit
    are implemented in terms of the newly introduced __find_first_bit
    and __find_first_zero_bit.

    This patch does not remove the i386-specific implementation,
    but it does switch i386 to use the generic functions by setting
    GENERIC_FIND_FIRST_BIT=y for X86_32.

    Signed-off-by: Alexander van Heukelum
    Signed-off-by: Ingo Molnar

    Alexander van Heukelum
     
  • This moves an optimization for searching constant-sized small
    bitmaps form x86_64-specific to generic code.

    On an i386 defconfig (the x86#testing one), the size of vmlinux hardly
    changes with this applied. I have observed only four places where this
    optimization avoids a call into find_next_bit:

    In the functions return_unused_surplus_pages, alloc_fresh_huge_page,
    and adjust_pool_surplus, this patch avoids a call for a 1-bit bitmap.
    In __next_cpu a call is avoided for a 32-bit bitmap. That's it.

    On x86_64, 52 locations are optimized with a minimal increase in
    code size:

    Current #testing defconfig:
    146 x bsf, 27 x find_next_*bit
    text data bss dec hex filename
    5392637 846592 724424 6963653 6a41c5 vmlinux

    After removing the x86_64 specific optimization for find_next_*bit:
    94 x bsf, 79 x find_next_*bit
    text data bss dec hex filename
    5392358 846592 724424 6963374 6a40ae vmlinux

    After this patch (making the optimization generic):
    146 x bsf, 27 x find_next_*bit
    text data bss dec hex filename
    5392396 846592 724424 6963412 6a40d4 vmlinux

    [ tglx@linutronix.de: build fixes ]

    Signed-off-by: Ingo Molnar

    Alexander van Heukelum
     
  • The versions with inline assembly are in fact slower on the machines I
    tested them on (in userspace) (Athlon XP 2800+, p4-like Xeon 2.8GHz, AMD
    Opteron 270). The i386-version needed a fix similar to 06024f21 to avoid
    crashing the benchmark.

    Benchmark using: gcc -fomit-frame-pointer -Os. For each bitmap size
    1...512, for each possible bitmap with one bit set, for each possible
    offset: find the position of the first bit starting at offset. If you
    follow ;). Times include setup of the bitmap and checking of the
    results.

    Athlon Xeon Opteron 32/64bit
    x86-specific: 0m3.692s 0m2.820s 0m3.196s / 0m2.480s
    generic: 0m2.622s 0m1.662s 0m2.100s / 0m1.572s

    If the bitmap size is not a multiple of BITS_PER_LONG, and no set
    (cleared) bit is found, find_next_bit (find_next_zero_bit) returns a
    value outside of the range [0, size]. The generic version always returns
    exactly size. The generic version also uses unsigned long everywhere,
    while the x86 versions use a mishmash of int, unsigned (int), long and
    unsigned long.

    Using the generic version does give a slightly bigger kernel, though.

    defconfig: text data bss dec hex filename
    x86-specific: 4738555 481232 626688 5846475 5935cb vmlinux (32 bit)
    generic: 4738621 481232 626688 5846541 59360d vmlinux (32 bit)
    x86-specific: 5392395 846568 724424 6963387 6a40bb vmlinux (64 bit)
    generic: 5392458 846568 724424 6963450 6a40fa vmlinux (64 bit)

    Signed-off-by: Alexander van Heukelum
    Signed-off-by: Ingo Molnar

    Alexander van Heukelum
     

29 Jan, 2008

1 commit


27 Mar, 2006

2 commits

  • This patch introduces the C-language equivalents of the functions below:

    int ext2_set_bit(int nr, volatile unsigned long *addr);
    int ext2_clear_bit(int nr, volatile unsigned long *addr);
    int ext2_test_bit(int nr, const volatile unsigned long *addr);
    unsigned long ext2_find_first_zero_bit(const unsigned long *addr,
    unsigned long size);
    unsinged long ext2_find_next_zero_bit(const unsigned long *addr,
    unsigned long size);

    In include/asm-generic/bitops/ext2-non-atomic.h

    This code largely copied from:

    include/asm-powerpc/bitops.h
    include/asm-parisc/bitops.h

    Signed-off-by: Akinobu Mita
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Akinobu Mita
     
  • This patch introduces the C-language equivalents of the functions below:

    unsigned logn find_next_bit(const unsigned long *addr, unsigned long size,
    unsigned long offset);
    unsigned long find_next_zero_bit(const unsigned long *addr, unsigned long size,
    unsigned long offset);
    unsigned long find_first_zero_bit(const unsigned long *addr,
    unsigned long size);
    unsigned long find_first_bit(const unsigned long *addr, unsigned long size);

    In include/asm-generic/bitops/find.h

    This code largely copied from: arch/powerpc/lib/bitops.c

    Signed-off-by: Akinobu Mita
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Akinobu Mita
     

09 Jan, 2006

1 commit


17 Apr, 2005

1 commit

  • 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!

    Linus Torvalds