lkml.org 
[lkml]   [2008]   [Apr]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH] bitops: remove "optimizations"
    From
    From: David Miller <davem@davemloft.net>
    Date: Tue, 29 Apr 2008 03:03:32 -0700 (PDT)

    > From: Thomas Gleixner <tglx@linutronix.de>
    > Date: Tue, 29 Apr 2008 12:01:02 +0200 (CEST)
    >
    > > Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    >
    > Acked-by: David S. Miller <davem@davemloft.net>

    Ironically, I just bisected sparc64 bootup failures to the following
    changeset. It's very late here, and I haven't looked into the
    details, but it seems to wedge in free_area_init_nodes() on a non-NUMA
    system with CONFIG_NUMA disabled.

    Isn't it funny that this optimization not only was useless, but also
    broke things. :-/

    64970b68d2b3ed32b964b0b30b1b98518fde388e is first bad commit
    commit 64970b68d2b3ed32b964b0b30b1b98518fde388e
    Author: Alexander van Heukelum <heukelum@mailshack.com>
    Date: Tue Mar 11 16:17:19 2008 +0100

    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>

    :040000 040000 c0407f7df7dc5333c78c300780931a269ae0dedd 2f6ef634a35b6dd46e40ea70128c39a742e60501 M include
    :040000 040000 556ee6ccb15cdbb1aa5a690c732a5492d58dfe6f 937d05977f46056c12b5da64ca62959c06a912c0 M lib


    \
     
     \ /
      Last update: 2008-04-29 14:37    [W:4.280 / U:0.184 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site