* Adrian Bunk <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
