Re: [PATCH 2/7] kernel: fix out of tree module builds

[Enrico Scholz <enrico.scholz@sigma-chemnitz.de>]

Richard Purdie <richard.purdie@linuxfoundation.org> writes:

> In summary, basically, yes. The kernel source is huge and we were
> compressing/decompressing it in several places on the critical path.
> People were struggling to develop kernels using the system due to the
> overhead.

I do not see how the new system makes it easier to "develop kernels".  Due
to polluting sources with .config and related files, KBUILD_OUTPUT/VPATH
builds are not possible from this tree.

In my experience, it is also a pain to jump between the different
directories and tools like 'cscope' are not prepared of it.

And more importantly: the new system lowers end user experience
significantly because kernel messages will show absolute buildsystem
paths now; e.g.

| /srv/.oe/bld/e6ca2c38-c20d-f57f-7eca-ffc0aaa2f0bd/sysroots/kk-trizeps6/usr/src/kernel/drivers/usb/core/hub.c

vs.

| drivers/usb/core/hub.c

VPATH builds might be interesting for QA (e.g. building from same source
with different configuration) but should not be used for final builds.


> Whilst this approach does bypass some parts of the system, I do believe
> the benefits are worth it. We're talking about making the kernel build
> time about three times faster iirc,

I can not reproduce these numbers here; I get (after a '-c cleanall' and
'ccache -c'):

  | Task                         | time (old) | time (new) |
  |------------------------------+------------+------------|
  | do_bundle_initramfs          |   0.087052 |   0.034955 |
  | do_compile                   | 128.242407 | 133.723027 |
  | do_compile_kernelmodules     |  84.415655 |  83.249409 |
  | do_compile_prepare           |   2.885401 |   1.714159 |
  | do_configure                 |   6.202691 |   4.340526 |
  | do_deploy                    |  13.991785 |   14.07096 |
  | do_fetch                     |   0.210244 |   1.425304 |
  | do_generate_initramfs_source |   0.063915 |   0.041925 |
  | do_install                   |  16.190504 |    2.91906 |
  | do_package                   | 120.823374 |  16.422429 |
  | do_package_qa                |            |   2.557622 |
  | do_package_write_ipk         |   42.50694 |   29.57585 |
  | do_packagedata               |   1.612542 |   0.462001 |
  | do_patch                     |   0.186583 |   0.011232 |
  | do_populate_lic              |   0.795013 |   0.135186 |
  | do_populate_sysroot          |  10.142978 |   0.533519 |
  | do_rm_work                   |   1.762486 |   0.447187 |
  | do_rm_work_all               |   0.049144 |   0.030964 |
  | do_sizecheck                 |   0.054441 |   0.035806 |
  | do_strip                     |   0.049917 |   0.030841 |
  | do_uboot_mkimage             |   9.032543 |   12.83624 |
  | do_unpack                    |   6.695678 |   9.322173 |

  | old | 446.00129 |
  | new | 313.92038 |

Although the 'new' system is faster, this is gained mainly by the
'do_package' task which does not seem to be comparable.  The new
method will create only a very small 'kernel-dev' subpackage:

   1,1M    tmp/deploy/ipk/kk_trizeps6/kernel-dev_3.14...

vs.

    36M    tmp/deploy/ipk/kk_trizeps6/kernel-dev_3.14...

so the old task can be improved either by removing some files, or the
new task misses files.



Enrico