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

[Ingo Molnar]

* Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/