* jim owens <jowens@xxxxxx> wrote: > Ingo Molnar wrote: >> >> One interpretation of the numbers would be that core kernel hackers are >> more inline-happy, maybe because they think that their functions are >> more important to inline. >> >> Which is generally a fair initial assumption, but according to the >> numbers it does not appear to pay off in practice as it does not result >> in a smaller kernel image. > > I think people over-use inline for the opposite reason. Note that i talked about the core kernel (kernel/*.c) specifically. > They are taught: > - use inline functions instead of macros > - inlining functions makes your code run faster > > They also know inlining may increase program object size. That inlining > will reduce object size on many architectures if the function is small > is just a happy side effect to them. Core kernel developers tend to be quite inline-conscious and generally do not believe that making something inline will make it go faster. That's why i picked kernel/built-in.o as a good "best of breed" entity to measure - if then that is an area where we have at least the chance to do a "kernel coders know best when to inline" manual inlining job. But despite a decade of tuning and systematic effort in that area, the numbers suggest that we dont. (if someone has different numbers or different interpretation, please share it with us.) My goal is to make the kernel smaller and faster, and as far as the placement of 'inline' keywords goes, i dont have too strong feelings about how it's achieved: they have a certain level of documentation value [signalling that a function is _intended_ to be lightweight] but otherwise they are pretty neutral attributes to me. So we want all the mechanisms in place to constantly press towards a smaller and faster kernel, with the most efficient use of development resources. Some techniques work in practice despite looking problematic, some dont, despite looking good on paper. This might be one of those cases. Or not :-) Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
