]> pilppa.com Git - linux-2.6-omap-h63xx.git/commit
x86, generic: optimize find_next_(zero_)bit for small constant-size bitmaps
authorAlexander van Heukelum <heukelum@mailshack.com>
Tue, 11 Mar 2008 15:17:19 +0000 (16:17 +0100)
committerIngo Molnar <mingo@elte.hu>
Sat, 26 Apr 2008 17:21:16 +0000 (19:21 +0200)
commit64970b68d2b3ed32b964b0b30b1b98518fde388e
tree7d8eb5ea3ab1a841afa0f7ae1c65e7be4a9ca690
parent60b6783a044a55273b637983f52965c2808a6b86
x86, generic: optimize find_next_(zero_)bit for small constant-size bitmaps

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 <mingo@elte.hu>
include/asm-generic/bitops/find.h
include/asm-x86/bitops.h
include/asm-x86/bitops_64.h
include/linux/bitops.h
lib/find_next_bit.c