lkml.org 
[lkml]   [2006]   [Jan]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch 00/2] improve .text size on gcc 4.0 and newer compilers

    * Adrian Bunk <bunk@stusta.de> 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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-01-02 15:08    [W:4.154 / U:0.232 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site