Re: [patch 00/2] improve .text size on gcc 4.0 and newer compilers

[Ingo Molnar]

* Adrian Bunk <bunk@xxxxxxxxx> wrote:

> > > > Your uninline patch might be simple, but the safe way would be Arjan's 
> > > > approach to start removing all the buggy inline's from .c files.
> > > 
> > > sure, that's another thing to do, but it's also clear that there's no 
> > > reason to force inlines in the -Os case.
> > > 
> > > There are 22,000+ inline functions in the kernel right now (inlined 
> > > about a 100,000 times), and we'd have to change _thousands_ of them. 
> > > They are causing an unjustified code bloat of somewhere around 20-30%. 
> > > (some of them are very much justified, especially in core kernel code)
> > 
> > my patch attacks the top bloaters, and gains about 30k to 40k (depending
> > on compiler). Gaining the other 300k is going to be a LOT of churn, not
> > just in amount of work... so to some degree my patch shows that it's a
> > bit of a hopeless battle.
> 
> A quick grep shows at about 10.000 inline's in .c files, and nearly 
> all of them should be removed.
> 
> Yes this is a serious amount of work, but it's an ideal janitorial 
> task.

oh, it is certainly an insane amount of janitorial work - which is also 
precisely why this well-known and seemingly trivial problem has 
escallated so much!

the nontrivial thing is that the moment trivial things get widespread, 
_the mechanism_ needs a change. I.e. the 'widespread inlines' arent the 
big problem, the big problem is that the widespread inlines _got 
widespread_. I'm not sure whether i'm being clear enough: think of the 
22,000 inlines as a symptom of a deeper problem, not as the problem 
itself. That is i am trying to get through (to you and to others).

trying to attack a problem that has a number-of-changes size of 22,000 
is also trivially _futile_, we'll be quickly overwhelmed by the 
underlying problem again, if it's not addressed.

both Arjan and me are trying to attack the underlying problem, while 
also fixing all the results of that problem. But the main focus is on 
mapping and eliminating the _hidden_ problem, not on the very visible 
'symptoms'. The symptoms are easy to fix! I do think the underlying 
problem is fixable too, but i find it slightly frustrating that most 
people are focused on the symptoms, missing the bigger picture.

what is the 'deeper problem'? I believe it is a combination of two 
(well-known) things:

  1) people add 'inline' too easily
  2) we default to 'always inline'

problem #1 is very hard to influence, because it's a basic psychology 
issue. Pretty much the only approach to fix this is to educate people.  
But it is hard to change the ways people code, and it's a long-term 
thing with no reasonable expectation of success. So while we can and 
should improve education of this issue (this thread will certainly raise 
awareness of it), we cannot rely on it alone.

i think the only realistic approach is to attack component #2: do not 
default to 'always inline' but default to 'inline if the compiler agrees 
too'. I do think we should default to 'compiler decides' (when using a 
gcc4 compiler), as this also has some obvious advantages:

 - different inlining when compiler optimizes for size not for speed

changing this also means we need to map a few trivial cases where kernel 
code relies on inlining (or relies on non-inlining), but those are 
fortunately easy and mostly well-known.

taking Arjan's patch alone, or running a script to change all static 
inlines in .c files to non-inline, without doing some of the other 
changes i'm proposing has a number of disadvantages:

 - it leaves the defaults in place, and we'll again gain ~50-100 new 
   'incorrect' inlines per week as we did until today. Barring the 
   initial few weeks of enthusiasm, nobody will really address that in 
   the long run, and we'll be back to square one.

 - it likely destroys the inlines there _were_ put into .c files 
   judiciously and correctly. The keyword 'inline' is a hint for gcc 
   which increases the likelyhood it will be inlined. Removing them an 
   bloc is _wrong_ and punishes the 'good guys', while still allowing 
   the 'bad guys' to continue business as usual.

so all in one, unless we attack #1 or #2 _with a bigger effective effort 
than we spend on attacking the symptoms_, we will only achieve a 
temporary, short-term reprieve.

	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/