[lkml]   [2008]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch] x86: phase out forced inlining

    * Sam Ravnborg <> wrote:

    > > Subject: x86: phase out forced inlining
    > Any particular reason you made the patch x86 specific?

    to keep it simple for now. Some of the other 24 architectures are
    seriously under-tested and while we can make sure x86 works well, i dont
    test the others. If it works out fine on x86 it can be generalized.

    > > +config OPTIMIZE_INLINING
    > Other (not all) config options that deal with gcc behaviour are named
    > CC_*. But they mostly impact gcc options. CC_OPTIMIZE_INLINING would
    > match the naming of CC_OPTIMIZE_SIZE, except in the latter OPTIMIZE
    > refer to the -O option.
    > CC_DEFAULT_INLINE may give the right associations?

    i really wanted to name it 'optimize' - because that's what it does. We
    just lost 2 years of uninlining advantage due to CONFIG_FORCED_INLINING
    not working and nobody actually connecting the dots that the lack of
    'forced inlining' should have resulted in a 'smaller image' and report
    it as a bug.

    > > + test gcc for this.
    > Would it be worth here to mention that stuff that really needs
    > inlining should use __always_inle and not inline?

    i think people know that, but i'll add it.

    > > + */
    > > +# define inline inline __attribute__((always_inline))
    > > +# define __inline__ __inline__ __attribute__((always_inline))
    > > +# define __inline __inline __attribute__((always_inline))
    > > +#endif
    > A quick google did not tell me the difference between inline,
    > __inline, __inline__. But it turned out the december 2005 thread where
    > there was a lenghty discussion about trusting gcc with respect to
    > inlining. It is not the subject of this patch but I just wondered why
    > we need all these variants.

    i dont know why they there are so many variants, but all of them seem to
    be used throughout the kernel:

    inline : 25648
    __inline__ : 1380
    __inline : 368

    so obviously the patch has to cover them.

    a few stats about inlines btw:

    - in v2.6.24 there were 26452 inlines in the kernel in 8083114 lines of
    code - or one inline per 305.6 lines of code.

    - in v2.6.25-rc3 there are 27396 inlines in the kernel in 8387992 lines
    of code - or one inline per 308.2 lines of code.

    at that rate, all inlines will be removed in about 117.5 kernel cycles -
    which, if we count with 90 day release cycles, will be finished in about
    29 years.

    if we only look at include/linux/ files [which have the largest inlining
    effect], the rate of inline removal is in fact negative: in v2.6.24 we
    had one inline per 59.1 lines, in 2.6.25-to-be we have one inline per
    57.9 lines.

    so i'm not holding my breath and i'm going for the much more immediate


     \ /
      Last update: 2008-03-04 17:49    [W:0.023 / U:32.568 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site