Re: [bloat] Measuring header file bloat effects on kernel buildperformance: a more than 2x slowdown ...

[Paul Gortmaker]

On Mon, May 23, 2011 at 5:09 AM, Ingo Molnar <mingo@xxxxxxx> wrote:
>

[...]

>
> A surprisingly large chunk are all the module.h details which brings in details
> like large elf.h definitions - despite pid.c only relying on the module code
> for the spurious use of EXPORT_SYMBOL primitives. Fixing this would cause no
> runtime overhead AFAICS.

I started working on the above since it seemed like it would be an interesting
puzzle to untangle - that is before I realized how involved it would be.  :)

It is do-able, but not as simple as it 1st might seem.  At the moment, if you
touch linux/module.h and rebuild, the time is within one or two seconds of
a fresh build - some 1670 compiles (for a typical x86-64 defconfig).  So
module.h is pretty much 99% pervasive.  With my tree so far, the same
touch builds close to 500 less files, is done in ~20% less time, and I've
still many changes yet to make....

Things that become evident upon attacking this:

1) Separating out the EXPORT_SYMBOL stuff just alone by itself largely
does nothing, because there are ~35 files in include/* which will directly
include linux/module.h regardless of whether your file wanted it or not.

2) The biggest culprit is linux/device.h, since it finds its way into almost
everything it seems.  One has to clean everything else up, and then
rebase this type of change to last, so the tree remains bisectable.

3) Dealing with #2 reveals that *lots* of drivers/files never even had a line
for #include <linux/module.h> -- they were happy to have it implicitly
appear via some unknown include chain and simply ride the wave.

4) It isn't just the presence of module.h that people were implicitly taking
advantage of -- since module.h itself includes 95% of the known world, I
found files that were getting stat.h, sched.h, even asm/*.h etc. via the
implicit presence of module.h

5) The combination of #3 and #4 makes for a lot of commits, as  I'm trying
to keep them separated along subsystem/maintainer boundaries.

Anyways, I just wanted to mention this was underway, but I don't see it
being 100% done in the small amount of time left in this merge window.

The current tree is here if anyone wants to poke at it and comment on it
while I continue to plug away at the task.  x86, x86-64 and powerpc-64
defconfigs have been tested to build OK.

git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-2.6.git
module.h-split-May27

http://git.kernel.org/?p=linux/kernel/git/paulg/linux-2.6.git;a=shortlog;h=refs/heads/module.h-split-May27

Paul.

>
> Another big chunk are the RCU definitions and APIs. These too are inlined for
> performance reasons - and that seems justified.
>
> Anway, what i tried to demonstrate with this mail how much *real* slowdown in
> the kernel build our current header file bloat is causing. We could literally
> halve our kernel build times if we fixed this!
>
> Thanks,
>
--
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/