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

Ingo Molnar
2009-01-10T01:20:50Z

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Sat, 10 Jan 2009, Ingo Molnar wrote:
> >
> > 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.
>
> Umm. No we didn't. We've never changed it. It was "always inline" back in

s/changed the behavior/overrode the behavior

> the old days, and then we had to keep it "always inline", which is why
> we override the default gcc meaning with the preprocessor.
>
> Now, OPTIMIZE_INLINING _tries_ to change the semantics, and people are
> complaining..

But i'd definitely argue that the Linux kernel definition of 'inline' was
always more consistent than GCC's. That was rather easy as well: it doesnt
get any more clear-cut than 'always inline'.

Nevertheless the question remains: is 3% on allyesconfig and 1% on
defconfig (7.5% in kernel/built-in.o) worth changing the kernel definition
for?

I think it is axiomatic that improving the kernel means changing it -
sometimes that means changing deep details. (And if you see us ignoring
complaints, let us know, it must not happen.)

So the question isnt whether to change, the question is: does the kernel
get 'better' after that change - and could the same be achieved
realistically via other means?

If you accept us turning all 30,000 inlines in the kernel upside down, we
might be able to get the same end result differently. You can definitely
be sure if people complained about this ~5 lines feature they will
complain about a tens of thousand of lines patch (and the followup changed
regime) ten or hundred times more fiercely.

And just in case it was not clear, i'm not a GCC apologist - to the
contrary. I dont really care which tool makes the kernel better, and i
wont stop looking at a quantified possibility to improve the kernel just
because it happens to be GCC that offers a solution.

Ingo