* Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > On Fri, 9 Jan 2009, Harvey Harrison wrote: > > > > __needs_inline? That would imply that it's for correctness reasons. > > .. but the point is, we have _thousands_ of inlines, and do you know > which is which? We've historically forced them to be inlined, and every > time somebody does that "OPTIMIZE_INLINE=y", something simply _breaks_. Having watched all the inline and anti-inline activites and patches of the past decade (and having participated in many of them) my strong impression is that any non-automated way is a fundamentally inhuman Don Quijote fight. The inlining numbers me and others posted seem to support that impression. Today we have in excess of thirty thousand 'inline' keyword uses in the kernel, and in excess of one hundred thousand kernel functions. We had a decade of hundreds of inline-tuning patches that flipped inline attributes on and off, with the goal of doing that job better than the compiler. Still a sucky compiler who was never faced with this level of inlining complexity before (up to a few short months ago when we released the first kernel with non-CONFIG_BROKEN-marked CONFIG_OPTIMIZE_INLINING feature in it) manages to do a better job at judging inlining than a decade of human optimizations managed to do. (If you accept that 1% - 3% - 7.5% code size reduction in important areas of the kernel is an improvement.) That improvement is systematic: it happens regardless whether it's core kernel developers who wrote the code, with years of kernel experience - or driver developers who came from Windows and might be inexperienced about it all and might slap 'inline' on every second random function. And it's not like the compiler was not allowed to inline important functions before: all static functions in .c it can (and do) inline if it sees fit. Tens of thousands of them. If we change 'inline' back to mean 'must inline' again, we have not changed the human dynamics of inlines at all and are back on square one. 'should_inline' or 'may_inline' will be an opt-in hint that will be subject to the same kind of misjudgements that resulted in the inlining situation to begin with. In .c files it's already possible to do that: by not placing an 'inline' keyword at all, just leaving the function 'static'. may_inline/inline_hint is a longer, less known and uglier keyword. So all the cards are stacked up against this new 'may inline' mechanism, and by all likelyhood it will fizzle and never reach any sort of critical mass to truly matter. Nor should it - why should humans do this if a silly tool can achieve something rather acceptable? So such a change will in essence amount to the effective removal of CONFIG_OPTIMIZE_INLINING. If we want to do that then we should do that honestly - and remove it altogether and not pretend to care. Fedora has CONFIG_OPTIMIZE_INLINING=y enabled today - distros are always on the lookout for kernel image reductor features. As of today i'm not aware of a single Fedora bugzilla that was caused by that. The upstream kernel did have bugs due to it - we had the UML breakage for example, and an older 3.x gcc threw an internal error on one of the (stale) isdn telephony drivers. Was Chris's crash actually caused by gcc's inlining decisions? I dont think it was. Historically we had far more compiler problems with CONFIG_CC_OPTIMIZE_SIZE=y - optimizing for size is a subtly complex and non-trivial compiler pass. 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
