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.
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.
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, [email protected] Ph:+61 7 34352815 http://www.SnapGear.com
Custom Embedded Solutions + Security Fx:+61 7 38913630 http://www.uCdot.org