* Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Sat, 10 Jan 2009, Ingo Molnar wrote:
> >
> > may_inline/inline_hint is a longer, less known and uglier keyword.
>
> Hey, your choice, should you decide to accept it, is to just get rid of
> them entirely.
>
> You claim that we're back to square one, but that's simply the way
> things are. Either "inline" means something, or it doesn't. You argue
> for it meaning nothing. I argue for it meaning something.
>
> If you want to argue for it meaning nothing, then REMOVE it, instead of
> breaking it.
>
> It really is that simple. Remove the inlines you think are wrong.
> Instead of trying to change the meaning of them.
Well, it's not totally meaningless. To begin with, defining 'inline' to
mean 'always inline' is a Linux kernel definition. So we already changed
the behavior - in the hope of getting it right most of the time and in the
hope of thus improving the kernel.
And now it appears that in our quest of improving the kernel we can
further tweak that (already non-standard) meaning to a weak "inline if the
compiler agrees too" hint. That gives us an even more compact kernel. It
also moves the meaning of 'inline' closer to what the typical programmer
expects it to be - for better or worse.
We could remove them completely, but there are a couple of practical
problems with that:
- In this cycle alone, in the past ~2 weeks we added another 1300 inlines
to the kernel. Do we really want periodic postings of:
[PATCH 0/135] inline removal cleanups
... in the next 10 years? We have about 20% of all functions in the
kernel marked with 'inline'. It is a _very_ strong habit. Is it worth
fighting against it?
- Headers could probably go back to 'extern inline' again. At not small
expense - we just finished moving to 'static inline'. We'd need to
guarantee a library instantiation for every header include file - this
is an additional mechanism with additional introduction complexities
and an ongoing maintenance cost.
- 'static inline' functions in .c files that are not used cause no build
warnings - while if we change them to 'static', we get a 'defined but
not used' warning. Hundreds of new warnings in the allyesconfig builds.
I know that because i just have removed all variants of 'inline' from all
.c files of the kernel, it's a 3.5MB patch:
3263 files changed, 12409 insertions(+), 12409 deletions(-)
x86 defconfig comparisons:
text filename
6875817 vmlinux.always-inline ( 0.000% )
6838290 vmlinux.always-inline+remove-c-inlines ( -0.548% )
6794474 vmlinux.optimize-inlining ( -1.197% )
So the kernel's size improved by half a percent. Should i submit it?
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
