lkml.org 
[lkml]   [2004]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 2.6.7-rc3-mm1
    Paul Jackson <pj@sgi.com> wrote:
    >
    > Do you recall why your i386-uninline-bitops.patch moves i386
    > find_next_bit() and find_next_zero_bit() out of line, but not
    > find_first_zero_bit() nor find_first_bit()?

    They're the two non-leaf functions - they expand other inlines and end up
    quite big.

    > Perhaps someone else has further insight to the tradeoffs here, such as
    > a 'recommended size', above which most routines should be not inlined,
    > except in special cases.

    Hard call. Lots of hand-waving is involved.

    Yes, an aggregate reduction in kernel text size is a good thing, but the
    main reason for uninlining things is for performance: reduction of icache
    footprint.

    If an inline function is expanded several times in, say, fs/dcache.c then
    it's a good candidate for uninlining, because it's probably the case that
    all the expanded versions are in icache simultaneously. But if a function
    is expanded once in ext2 and once in ext3 then it's less useful to uninline
    it, because it is rare that two different filesystem drivers are in use
    simultaneously.
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:03    [W:0.056 / U:0.252 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site