Bug 3517

Bruce, assigning to you as you said you were looking into it in parallel with Tom's more general performance analysis of the overall system.

This may need to be broken into multiple bugs, as I don't see how this one can really be sized/estimated in its current form.

I added some timestamping code to the bitbake log functions and also added some bbnote calls to do_package, to get a bit more breakdown there.  Here are the results of

[trz@empanada build]$ time bitbake linux-yocto

real	19m49.871s
user	24m9.529s
sys	7m43.978s

do_kernel_checkout: 6 sec
	    12:11:24
	    12:11:30

do_kernel_configme: 30 sec
	    12:12:21
	    12:12:51

do_kernel_configcheck: 7 sec
	12:13:35
	12:13:42

do_patch: 49 sec
	  12:11:31
	  12:12:20

do_configure: 44 sec
	12:12:51
	12:13:35

do_compile: 2:08 min
	12:13:42
	12:15:50

do_compile_kernelmodules: 37 sec
        12:15:50
	12:16:27

do_install: 3:14 min
	12:16:27
	12:19:41

do_package: 7:39 min
	12:19:42
		perform_packagecopy: 9 sec
			12:19:42
			12:19:51
		split_and_strip_files: 13 sec
			12:19:51
			12:20:04
		populate_packages: 2:36 min
			12:20:05
			12:22:41
		package_do_filedeps: 1:46 min
			12:22:41
			12:24:27
		package_do_shlibs: 18 sec
			12:24:27
			12:24:45
		package_do_pkgconfig: 8 sec
			12:24:45
			12:24:53
		emit_pkgdata: 10 sec
			12:24:53
			12:25:03
		do_package_qa: 24 sec
			12:25:03
			12:25:27
		sstate_task_postfunc: 1:54 min
			12:25:27
				sstate_create_package: 57 sec
					12:26:24
					12:27:21
			12:27:21
	12:27:21

do_package_write_rpm: 3:43 min
	12:27:21
		BUILDSPEC: 3:27 min
			12:27:32: Executing shell function BUILDSPEC
			12:30:59: Shell function BUILDSPEC finished
	12:31:04

do_populate_sysroot: 23 sec
	12:19:42
	12:20:05

Again, the packaging steps take more than half the time.

Also, trying to figure out why do_install takes so long, when it happens
almost instantaneously by hand, to see if it's a good case to analyze,
not really - turns out mostly the copy and pruning of the tree.

linux yocto do_install:

The actual modules_install is very fast:

NOTE 15:52:42: start modules_install
NOTE 15:52:44: end modules_install

The copy of the entire source tree takes 1:45 min:

NOTE 15:52:44: start install 4

        bbnote "start install 4"

        #
        # Copy the entire source tree. In case an external build directory is
        # used, copy the build directory over first, then copy over the source
        # dir. This ensures the original Makefiles are used and not the
        # redirecting Makefiles in the build directory.
        #
        # work and sysroots can be on different partitions, so we can't rely on
        # hardlinking, unfortunately.
        #
        cp -fR * $kerneldir
        cp .config $kerneldir
        if [ "${S}" != "${B}" ]; then
                cp -fR ${S}/* $kerneldir
        fi
        install -m 0644 ${KERNEL_OUTPUT} $kerneldir/${KERNEL_IMAGETYPE}
        install -m 0644 System.map $kerneldir/System.map-${KERNEL_VERSION}


NOTE 15:54:29: start install 5

cleaning and removing files not needed takes 1:41 min:

NOTE 15:54:29: start install 5

        bbnote "start install 5"

        #
        # Clean and remove files not needed for building modules.
        # Some distributions go through a lot more trouble to strip out
        # unecessary headers, for now, we just prune the obvious bits.
        #
        # We don't want to leave host-arch binaries in /sysroots, so
        # we clean the scripts dir while leaving the generated config
        # and include files.
        #
        oe_runmake -C $kerneldir CC="${KERNEL_CC}" LD="${KERNEL_LD}" clean
        make -C $kerneldir _mrproper_scripts
        find $kerneldir -path $kerneldir/lib -prune -o -path $kerneldir/tools -prune -o -path $ker\
neldir/scripts -prune -o -name "*.[csS]" -exec rm '{}' \;
        find $kerneldir/Documentation -name "*.txt" -exec rm '{}' \;

NOTE 15:56:10: start install 6

One thing we could do is create a hardlink copy of the sources first, prune that, and then perform the regular copy. That might save time by not copying files we will later remove.

If we can combine the find commands together, that might also save some time.

I've received a patch that addresses some of the install time issues. Testing it here.

Please don't make one big kernel-modules package.

Right now each module can have extra postinst with autoload or extra kernel parameters provided from MACHINE.conf. That would get more ugly with one bit kernel-modules.

Also that extra diskspace needed for all modules is significant on many devices, now I can enable any extra module in kernel config when even single user asks for it, if it gets packaged as one big package then I'll have to decide if it's worth it putting that module on every rootfs just to make one use happy.

Martin: no worries, we would never break the existing behaviour in such 
a drastic way. Both the use case you describe and a big kernel modules
package should be able to co-exist and meet different needs. Anything
that happens would be optional, and not mandatory with existing techniques
being maintained.

With the cpio kernel changes, Peter Seebach's pseudo updates and RPs general
packaging updates for 1.4, we have likely come as far as we can with this for the 
1.4 release.

Bumping this to M1.5 to take a final look at performance before closing the bugzilla entry.

This has been resolved via a collection of changes:

  - packaging changes by Richard
  - pseudo changes by seebs
  - kernel file handling changes by others

Marking as Verified. The data here https://wiki.yoctoproject.org/wiki/Performance_Test#1.4_Perfomance_Data shows a clear improvement from about 16:30 min in M1 to 11:20 min in M5.