[lkml]   [2003]   [Jul]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [uClinux-dev] Kernel 2.6 size increase - get_current()?
    On Thursday, Jul 24, 2003, at 23:22 US/Central, Otto Solares wrote:

    > On Thu, Jul 24, 2003 at 11:20:00PM +0200, J.A. Magallon wrote:
    >> Or you just define must_inline, and let gcc inline the rest of
    >> 'inlines',
    >> based on its own rule of functions size, adjusting the parameters
    >> to gcc to assure (more or less) that what is inlined fits in cache of
    >> the processor one is building for...
    >> (this can be hard, help from gcc hackers will be needed...)
    > IMO just a CONFIG_INLINE_FUNCTIONS will work, if you
    > want to conserve space in detriment of speed simply
    > don't select this option, else you have speed but
    > a big kernel.

    Inlines don't always help performance (depending on cache sizes, branch
    penalties, frequency of code access...), but they do always increase
    code size.

    I believe the point Alan was trying to make is not that we should have
    more or less inlines, but we should have smarter inlines. I.E. don't
    just inline a function to "make it fast"; think about the implications
    (and ideally measure it, though I think that becomes problematic when
    so many other factors can affect the benefit of a single inlined
    function). The specific example he gave was inlining code on the fast
    path, while accepting branch/cache penalties for non-inlined code on
    the slow path.

    Hollis Blanchard
    IBM Linux Technology Center

    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 13:47    [W:0.019 / U:10.016 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site