[lkml]   [2004]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 2.6.7-rc3-mm1
    Paul Jackson <> 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

    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
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

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