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

Andrew Morton
2009-01-10T01:42:29Z

On Sat, 10 Jan 2009 02:01:25 +0100 Ingo Molnar <mingo@elte.hu> wrote:

>
> * 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.

Who "reviewed" all that?

> 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?

A side-effect of the inline fetish is that a lot of it goes into header
files, thus requiring that those header files #include lots of other
headers, thus leading to, well, the current mess.