Skip to content
Snippets Groups Projects
Select Git revision
  • 64970b68d2b3ed32b964b0b30b1b98518fde388e
  • vme-testing default
  • ci-test
  • master
  • remoteproc
  • am625-sk-ov5640
  • pcal6534-upstreaming
  • lps22df-upstreaming
  • msc-upstreaming
  • imx8mp
  • iio/noa1305
  • vme-next
  • vme-next-4.14-rc4
  • v4.14-rc4
  • v4.14-rc3
  • v4.14-rc2
  • v4.14-rc1
  • v4.13
  • vme-next-4.13-rc7
  • v4.13-rc7
  • v4.13-rc6
  • v4.13-rc5
  • v4.13-rc4
  • v4.13-rc3
  • v4.13-rc2
  • v4.13-rc1
  • v4.12
  • v4.12-rc7
  • v4.12-rc6
  • v4.12-rc5
  • v4.12-rc4
  • v4.12-rc3
32 results

find_next_bit.c

  • Alexander van Heukelum's avatar
    64970b68
    x86, generic: optimize find_next_(zero_)bit for small constant-size bitmaps · 64970b68
    Alexander van Heukelum authored
    
    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: default avatarIngo Molnar <mingo@elte.hu>
    64970b68
    History
    x86, generic: optimize find_next_(zero_)bit for small constant-size bitmaps
    Alexander van Heukelum authored
    
    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: default avatarIngo Molnar <mingo@elte.hu>