Re: [PATCH -v7][RFC]: mutex: implement adaptive spinning

[Ingo Molnar <mingo@elte.hu>]

* Linus Torvalds <torvalds@linux-foundation.org> 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