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.
-
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