The code I've noticed uses macros when it wants stuff inlined, and uses
explicit inlining only as a way to write very long functions as multiple
functions (for readability) yet avoid the function call overhead. I
haven't seen explicit inlining anywhere else, and I've seen some huge
macros I'd give a compiler the option to not inline...but I didn't write
the code and I haven't read the whole kernel.
So, what makes it a win for all architectures to not suggest that the
compiler inline functions when it believes it would be faster, just
because a few functions ought not to be inlined and a few functions
which probably should be inlined are marked as such? I'd say tell the
compiler to inline and tell it what to not inline. That goes double for
loop unrolling; to mangle a metaphor, what's good for the goose is not
always good for the duck or the swan.
> It is quite possible that you are beaten by the assembler constraint problems
> discussed in other messages in this thread - they cause problems when the
> compiler has to manage lots of variables in only a few registers, and both
> loop unrolling and automatic inlining eat registers a lot.
If that's a problem, then the compiler should balance the spillage against
the potential gain (and the profiling data or hints, if any) and do a
reasonable approximation of the Right Thing(tm).
> One of the main performance advantages of Linux compared to bloated monsters
> like Solaris is that Linux generally uses simpler code which doesn't steal
> most of the L1 cache when you enter the kernel. Loop unrolling and automatic
> inlining cause code size increases which cancels that advantage.
When it's smart to unroll, you're trading off potential (even probable)
cache hits tomorrow for a definite gain today. When it's smart to inline,
you save the jumping and pushing and popping and don't even increase the
code size "experienced" unless a trip through the kernel calls that
inlined function multiple times from multiple different places.
Keith
-- "The avalanche has already started; |Linux: http://www.linuxhq.com |"Zooty, it is too late for the pebbles to |KDE: http://www.kde.org | zoot vote." Kosh, "Believers", Babylon 5 |Keith: kwrohrer@enteract.com | zoot!" www.midwinter.com/lurk/lurker.html |http://www.enteract.com/~kwrohrer | --Rebo- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/