19 May, 2010

1 commit


05 May, 2010

1 commit

  • Fix function prototype visibility issues when compiling for non-x86
    architectures. Tested with crosstool
    (ftp://ftp.kernel.org/pub/tools/crosstool/) with alpha, ia64 and sparc
    targets.

    Signed-off-by: Borislav Petkov
    LKML-Reference:
    Signed-off-by: H. Peter Anvin

    Borislav Petkov
     

07 Apr, 2010

2 commits


07 Mar, 2010

1 commit

  • Rename for_each_bit to for_each_set_bit in the kernel source tree. To
    permit for_each_clear_bit(), should that ever be added.

    The patch includes a macro to map the old for_each_bit() onto the new
    for_each_set_bit(). This is a (very) temporary thing to ease the migration.

    [akpm@linux-foundation.org: add temporary for_each_bit()]
    Suggested-by: Alexey Dobriyan
    Suggested-by: Andrew Morton
    Signed-off-by: Akinobu Mita
    Cc: "David S. Miller"
    Cc: Russell King
    Cc: David Woodhouse
    Cc: Artem Bityutskiy
    Cc: Stephen Rothwell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Akinobu Mita
     

04 Feb, 2010

1 commit


29 Jan, 2010

1 commit


23 Apr, 2009

1 commit

  • Finds the first set bit in a 64 bit word. This is required in order
    to fix a bug in GFS2, but I think it should be a generic function
    in case of future users.

    Signed-off-by: Steven Whitehouse
    Reviewed-by: Christoph Lameter
    Reviewed-by: Willy Tarreau

    Steven Whitehouse
     

01 Jan, 2009

1 commit


29 Apr, 2008

2 commits

  • 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
     
  • BITS_PER_LONG is a signed value (32 or 64)

    DIV_ROUND_UP(nr, BITS_PER_LONG) performs signed arithmetic if "nr" is signed too.

    Converting BITS_TO_LONGS(nr) to DIV_ROUND_UP(nr, BITS_PER_BYTE *
    sizeof(long)) makes sure compiler can perform a right shift, even if "nr"
    is a signed value, instead of an expensive integer divide.

    Applying this patch saves 141 bytes on x86 when CONFIG_CC_OPTIMIZE_FOR_SIZE=y
    and speedup bitmap operations.

    Signed-off-by: Eric Dumazet
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Eric Dumazet
     

27 Apr, 2008

3 commits

  • Avoid a call to find_first_bit if the bitmap size is know at
    compile time and small enough to fit in a single long integer.
    Modeled after an optimization in the original x86_64-specific
    code.

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

    Alexander van Heukelum
     
  • 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
     

29 Mar, 2008

1 commit


20 Oct, 2007

3 commits

  • remove BITS_TO_TYPE macro

    I realized, that it is actually the same as DIV_ROUND_UP, use it instead.

    [akpm@linux-foundation.org: build fix]
    Signed-off-by: Jiri Slaby
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jiri Slaby
     
  • define global BIT macro

    move all local BIT defines to the new globally define macro.

    Signed-off-by: Jiri Slaby
    Cc: Paul Mackerras
    Cc: Benjamin Herrenschmidt
    Cc: Kumar Gala
    Cc: Dmitry Torokhov
    Cc: Jeff Garzik
    Cc: James Bottomley
    Cc: "Antonino A. Daplas"
    Cc: Russell King
    Acked-by: Ralf Baechle
    Cc: "John W. Linville"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jiri Slaby
     
  • define first set of BIT* macros

    - move BITOP_MASK and BITOP_WORD from asm-generic/bitops/atomic.h to
    include/linux/bitops.h and rename it to BIT_MASK and BIT_WORD
    - move BITS_TO_LONGS and BITS_PER_BYTE to bitops.h too and allow easily
    define another BITS_TO_something (e.g. in event.c) by BITS_TO_TYPE macro
    Remaining (and common) BIT macro will be defined after all occurences and
    conflicts will be sorted out in the patches.

    Signed-off-by: Jiri Slaby
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jiri Slaby
     

17 Oct, 2007

1 commit

  • Add support for MSI and MSI-X interrupt handling, including the ability
    to choose the desired interrupt method.

    Signed-off-by: Shannon Nelson
    Acked-by: David S. Miller
    [bunk@kernel.org: drivers/dma/ioat_dma.c: make 3 functions static]
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Shannon Nelson
     

27 Jan, 2007

1 commit


27 Mar, 2006

1 commit


26 Mar, 2006

1 commit

  • fls() takes an integer, so roundup_pow_of_two() is busted for ulongs larger
    than 2^32-1.

    Fix this by implementing and using fls_long().

    (Why does roundup_pow_of_two() return a long?)

    (Why is roundup_pow_of_two() __attribute_const__ whereas long_log2() is
    __attribute_pure__?)

    (Why does long_log2() suck so much? Because we were missing fls_long()?)

    Cc: Roland Dreier
    Cc: "Chen, Kenneth W"
    Cc: John Hawkes
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew Morton
     

04 Feb, 2006

1 commit


04 Jan, 2006

1 commit


15 Nov, 2005

1 commit

  • Fields obtained through cpuid vector 0x1(ebx[16:23]) and
    vector 0x4(eax[14:25], eax[26:31]) indicate the maximum values and might not
    always be the same as what is available and what OS sees. So make sure
    "siblings" and "cpu cores" values in /proc/cpuinfo reflect the values as seen
    by OS instead of what cpuid instruction says. This will also fix the buggy BIOS
    cases (for example where cpuid on a single core cpu says there are "2" siblings,
    even when HT is disabled in the BIOS.
    http://bugzilla.kernel.org/show_bug.cgi?id=4359)

    Signed-off-by: Suresh Siddha
    Signed-off-by: Andi Kleen
    Signed-off-by: Linus Torvalds

    Siddha, Suresh B
     

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