[lkml]   [2002]   [May]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectKBuild 2.5 Impressions
    I wanted to know how well kbuild 2.5 really works, so I got the patches
    from and gave them a test drive, comparing to
    old kbuild. First I did an out-of-the-box build, then I did 'touch
    fs/ext2/inode.c' and rebuilt. Results are as follows:

    old kbuild kbuild 2.5 Speedup

    First time build: 7 min 8 sec 5 min 55 sec 17%
    Incremental build: 25.94 sec 15.31 sec 41% :-)

    The test system is a 2 x 1 GHz server with scsi raid. Note that I only
    used one processor for the tests, as I normally do: in my experience,
    with old kbuild I spend more time picking up the broken pices than
    I save in compile time.

    For good measure, I did a make mrproper and rebuild with -j3. That
    completed in 3 minutes, 25 seconds. Very impressive, and what's more,
    running that make a second time completes in 12 seconds, as opposed to
    old make, which tends to erroneously rebuild a large number of files,
    and sometimes does not complete the job correctly.

    I have only one point on the curve, but it confirms what Keith has
    been saying. The incremental build speed is especially important to
    me. If I were working all the time on 2.5 - sadly, I'm not - I would
    without question be using kbuild 2.5 simply by reason of the fast
    incremental builds.

    Miscellaneous Notes

    Along the way, old kbuild did the usual wrong things:

    - In the incremental build, 6 files rebuilt that should not have been

    - Once, when I interrupted the make dep, subsequent make deps would
    no longer work, forcing me to do make mrproper and start again.

    - Way too much output to the screen

    I took a quick look into some of the kbuild 2.5 files, just
    to get a feeling for what they look like, and they look fine to me. For
    example, fs/ext2 has acquired a file, with contents that
    seem easily understandible. The syntax of these files is explained in
    the documentation, which is provided by the patch set, in:


    Reading through it, I found out about the NO_MAKEFILE_GEN, an option
    that promises to make a fast build system even faster for interative
    development, the type I always do. There is also a lot of informative
    design documentation. Amazingly, there is even postscript
    documentation. Full marks for documentation here.

    Note to Keith: this file needs to be in some obvious place on the
    sourceforge site.

    Both the old and new build systems failed the rename test: rename the
    root of the source tree and it will no longer build. The kbuild 2.5
    documentation explains:

    Unlike kbuild 2.4, renaming a source or object tree does not force a
    complete rebuild. After renaming any tree and updating the KBUILD_SRCTREE
    and KBUILD_OBJTREE variables, just run make. Unless you have changed any
    files, nothing should be rebuilt, however the make step must be run to save
    the new tree names ready for the install step.

    but this did not work for me. However, I do not doubt that it will

    Reading through the patches, I noticed there is some useful looking
    help text added for the makefile operations, but it wasn't immediately
    obvious how to get it. Reading the patch is, of course, one way.

    There is no Python anywhere to be seen in kbuild 2.5, for those who
    worry about that. It is coded in C, about 10,000 lines it seems.
    It has a simple built in database which I suppose accounts for some
    of that. For what it does, it seems quite reasonable. There is a
    bison-generated grammar, presumeably to parse the
    language. This is the proper way do do things - much more reliable
    and maintainable than a hand-coded parser, not to mention more
    efficient. Most of the rest of the patch consists of
    files. I can really see why this is a big job for Keith to maintain
    by himself: the maintainers really need to be involved. I doubt that
    it will be hard, and by appearances, there is no need for any
    particular arch to step up to kbuild 2.5 immediately, since the old
    build system still works. In any event, the 1386-specific part of
    the patch is only 700 or so lines long.

    The output that kbuild 2.5 generates is a vast improvment over old
    make. It's enough to see the progress of the make, while not
    obscuring the warnings. This by itself should help in cleaning up
    the tree.

    Note to anyone who wants to try this themselves: with the kbuild 2.5
    patches applied, nothing changes (and the old build system is used)
    unless you add '-f Makefile-2.5' to the make command. It does not
    appear to be necessary to supply a bzImage target, and in fact,
    Makefile-2.5 doesn't recognize it. That's basically all you have to

    Detailed Timings

    Old kbuild, out of the box build:

    424.18user 29.65system 7:07.94elapsed 106%CPU (0avgtext+0avgdata 0maxresident)k
    0inputs+0outputs (1552796major+1856222minor)pagefaults 0swaps

    touch fs/ext2/inode.c incremental build:

    24.08user 2.04system 0:25.94elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
    0inputs+0outputs (114294major+80954minor)pagefaults 0swaps

    kbuild 2.5, out of the box build:

    341.29user 18.71system 5:54.87elapsed 101%CPU (0avgtext+0avgdata 0maxresident)k
    0inputs+0outputs (1080599major+1427293minor)pagefaults 0swaps

    touch fs/ext2/inode.c incremental build:

    13.75user 1.76system 0:15.31elapsed 101%CPU (0avgtext+0avgdata 0maxresident)k
    0inputs+0outputs (122776major+59338minor)pagefaults 0swaps

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:26    [W:0.028 / U:5.824 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site