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

* Sam Ravnborg <sam@ravnborg.org> 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.

> > + */
> > +#ifndef CONFIG_OPTIMIZE_INLINING
> > +# 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
benefit of CONFIG_OPTIMIZE_INLINING=y.

Ingo


\
 
 \ /
  Last update: 2008-03-04 17:49    [from the cache]
©2003-2011 Jasper Spaans