Jivin Ihar Philips Filipau lays it down ...
> David McCullough wrote:
> >
> >A general comment on the use of inline throughout the kernel. Although
> >they may show gains on x86 platforms, they often perform worse on
> >embedded processors with limited cache, as well as adding size. I
> >can't see any way of coding around this though. As long as x86 is
> >driving influence, other platforms will jut have to deal with it as
> >best they can.
> >
>
> Actually I'm victim on over inlining too. Was at least.
> I was running some router on old Pentium's. I remember almost
> dramatical drop of performance with newer kernels because of inlining in
> net/*. But sure on Xeon P4 it boosts performance...
>
> Actually what I'm about.
> We have classical situation when we have mess of representation and
> intentions.
>
> Representation == 'inline', but intentions - 'inline or it will
> break' _and_ 'inline - it runs faster'.
> This obviously should be separated.
The biggest problem I see is that the inlines are done in header files
generally, and to stop them from inlining, you need to be able to
switch from an inline to a prototype in the header file. The code from
the header then needs to be added to a .o somewhere in the build for the
case where inlines are stripped out.
Other than providing non-critical inlines either on or off, I can't see
the level approach working all that well. A combination of levels that
work well on a few platforms may not work well at all on another.
Still, just the ability to reduce the inlines would be very useful.
Cheers,
Davidm
> even more.
>
> #define INLINE_LEVEL some_platform_specific_number
>
> ---------
>
> #define inline0 inline_always
>
> #if INLINE_LEVEL >= 1
> # define inline1 inline_always
> #else
> # define inline1
> #endif
> ...
> #if INLINE_LEVEL >= N
> # define inlineN inline_always
> #else
> # define inlineN
> #endif
>
> and so on, giving a platform chance to influence amount of inlining.
> better to put it into config with defined by platform defaults.
-- David McCullough, davidm@snapgear.com Ph:+61 7 34352815 http://www.SnapGear.com Custom Embedded Solutions + Security Fx:+61 7 38913630 http://www.uCdot.org - 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/
This archive was generated by hypermail 2b29 : Thu Jul 31 2003 - 22:00:22 EST