Bug 13113

Summary: Accelerate out-of-tree kernel module built in eSDK
Product: [Yocto Project Subprojects] eSDK Reporter: Zhaolong Zhang <zhangzl2013>
Component: eSDKAssignee: Paul Eggleton <bluelightning>
Status: RESOLVED WONTFIX QA Contact: Francisco Pedraza <francisco.j.pedraza.gonzalez>
Severity: enhancement    
Priority: Undecided CC: bruce.ashfield, randy.macleod, richard.purdie
Version: 2.7   
Target Milestone: ---   
Hardware: x86   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: No (bug/feature does not impact docs)
Attachments:
Description Flags
add STAGING_KERNEL_BUILDDIR and STAGING_KERNEL_DIR to eSDK none

Description Zhaolong Zhang 2019-01-03 07:09:13 UTC 
When building out-of-tree kernel modules in eSDK, it will always trigger a new rebuilding of kernel, which consumes lots of time.

I have tried to add virtual/kernel:do_shared_workdir to sstate cache and ship it with eSDK. On the eSDK side, run `bitbake linux-yocto -c shared_workdir` returns immediatlely, but `bitbake hello-mod` still triggers tasks from linux-yocto:do_fetch.

Adding this enhancement, it may need more time to generate the eSDK installer, but it will save considerably time at the eSDK user's side.
Comment 1 Richard Purdie 2019-01-03 16:25:34 UTC 
As discussed on the mailing list, this is not something we plan to support.

There is no technical reason that do_shared_workdir couldn't be an sstate task however the combination of the kernel source and the kernel compiled artifacts is large and results in a large sstate object. This means the time to build the kernel increases substantially.

Using the the object in a new build, or in an eSDK then results in having to transfer a large object over a network which is also slow unless its a local transfer so there is a double hit.

We made a decision as a project to just rebuild these pieces if/as needed rather than take the hit on the performance of the base kernel builds.

I appreciate that doesn't work for every workload but it is the tradeoff we decided to make.

If should be possible to patch do_shared_work to be an sstate task, however that code path will be quite different from the current behavior. We don't have the build resources to be able to test these two different code paths (does devtoool work with both, do external modules work with both etc). We're therefore unlikely to merge such a patch.

I've cc'd Bruce in case he has any different viewpoint on this.
Comment 2 Richard Purdie 2019-01-03 22:52:06 UTC 
Just to additionally note, there was a change submitted which makes it easier to implement this:

http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=aa83cb5264554dd1963042f905688afc796e98d0

I decided to merge that to at least make this option easier to implement.
Comment 3 Bruce Ashfield 2019-01-07 13:55:55 UTC 
Just documenting that my view is the same as RPs. What made it into the tree looks appropriate.
Comment 4 Zhaolong Zhang 2019-01-11 02:12:52 UTC 
Created attachment 4421 [details]
add STAGING_KERNEL_BUILDDIR and STAGING_KERNEL_DIR to eSDK

For anyone that may need this acceleration, this patch is for your reference.
Apply this patch as well as http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=aa83cb5264554dd1963042f905688afc796e98d0.

My testing result:

With patch:                        Orig:
===========                        =====
build and export eSDK:
----------------------
real    72m28.549s                 real    69m17.119s
user    653m12.390s                user    645m38.162s
sys     154m17.175s                sys     153m22.593s

eSDK installer size:
--------------------
4.6G                               4.4G

eSDK installation:
------------------
real    6m40.714s                  real    8m7.331s
user    24m19.822s                 user    25m41.045s
sys     4m17.492s                  sys     4m23.538s

build hello-mod in eSDK:
------------------------
real    0m31.966s                  real    21m7.686s
user    3m48.485s                  user    35m10.894s
sys     0m7.827s                   sys     15m3.837s