lkml.org 
[lkml]   [2009]   [Jan]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH -v7][RFC]: mutex: implement adaptive spinning

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

> On Fri, 9 Jan 2009, Harvey Harrison wrote:
> >
> > __needs_inline? That would imply that it's for correctness reasons.
>
> .. but the point is, we have _thousands_ of inlines, and do you know
> which is which? We've historically forced them to be inlined, and every
> time somebody does that "OPTIMIZE_INLINE=y", something simply _breaks_.

Having watched all the inline and anti-inline activites and patches of the
past decade (and having participated in many of them) my strong impression
is that any non-automated way is a fundamentally inhuman Don Quijote
fight.

The inlining numbers me and others posted seem to support that impression.

Today we have in excess of thirty thousand 'inline' keyword uses in the
kernel, and in excess of one hundred thousand kernel functions. We had a
decade of hundreds of inline-tuning patches that flipped inline attributes
on and off, with the goal of doing that job better than the compiler.

Still a sucky compiler who was never faced with this level of inlining
complexity before (up to a few short months ago when we released the first
kernel with non-CONFIG_BROKEN-marked CONFIG_OPTIMIZE_INLINING feature in
it) manages to do a better job at judging inlining than a decade of human
optimizations managed to do. (If you accept that 1% - 3% - 7.5% code size
reduction in important areas of the kernel is an improvement.)

That improvement is systematic: it happens regardless whether it's core
kernel developers who wrote the code, with years of kernel experience - or
driver developers who came from Windows and might be inexperienced about
it all and might slap 'inline' on every second random function.

And it's not like the compiler was not allowed to inline important
functions before: all static functions in .c it can (and do) inline if it
sees fit. Tens of thousands of them.

If we change 'inline' back to mean 'must inline' again, we have not
changed the human dynamics of inlines at all and are back on square one.
'should_inline' or 'may_inline' will be an opt-in hint that will be
subject to the same kind of misjudgements that resulted in the inlining
situation to begin with. In .c files it's already possible to do that: by
not placing an 'inline' keyword at all, just leaving the function
'static'.

may_inline/inline_hint is a longer, less known and uglier keyword. So all
the cards are stacked up against this new 'may inline' mechanism, and by
all likelyhood it will fizzle and never reach any sort of critical mass to
truly matter. Nor should it - why should humans do this if a silly tool
can achieve something rather acceptable?

So such a change will in essence amount to the effective removal of
CONFIG_OPTIMIZE_INLINING. If we want to do that then we should do that
honestly - and remove it altogether and not pretend to care.

Fedora has CONFIG_OPTIMIZE_INLINING=y enabled today - distros are always
on the lookout for kernel image reductor features. As of today i'm not
aware of a single Fedora bugzilla that was caused by that.

The upstream kernel did have bugs due to it - we had the UML breakage for
example, and an older 3.x gcc threw an internal error on one of the
(stale) isdn telephony drivers. Was Chris's crash actually caused by gcc's
inlining decisions? I dont think it was.

Historically we had far more compiler problems with
CONFIG_CC_OPTIMIZE_SIZE=y - optimizing for size is a subtly complex and
non-trivial compiler pass.

Ingo


\
 
 \ /
  Last update: 2009-01-10 00:17    [W:0.598 / U:1.240 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site