Bug 10983

Summary: [Test Case 810] Avoid cache reload for incremental development using a backgrounded bitbake server
Product: [Build System, Metadata & Runtime] BitBake Reporter: Jair Gonzalez <jair.de.jesus.gonzalez.plascencia>
Component: bitbakeAssignee: Richard Purdie <richard.purdie>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: Medium+ CC: oscarx.lopez.arandas, poky.bs.watcher, poky.watcher
Version: 2.3   
Target Milestone: 2.3 M4   
Hardware: x86   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: Don't know
Attachments:
Description Flags
bitbake_memres_vs_nonres.log
none
cache reload test log none

Description Jair Gonzalez 2017-01-27 17:20:31 UTC
Created attachment 3609 [details]
bitbake_memres_vs_nonres.log

STATUS: FAILED
BUILD: 2,3_M2 : 62d7d4130202d8ede16abf9e7d779361ca70847e
ENVIRONMENT: Fedora 24 x86_64
STEPS TO REPRODUCE: 1) get poky sources (1.5 +)

NOTE: The poky source should not have an already-made 'build' directory within

2) in a fresh shell session, source oe-init-build-env-memres
3) make any desired changes in local.conf
4) issue 'bitbake -n core-image-minimal'
-- see expected results --
5)change MACHINE to another acrhitecture in local.conf
6)  issue 'bitbake -n core-image-minimal'
-- see expected results --

7) close the bitbake server by issuing command: 'bitbake -m'

NOTE: Don't reuse this shell session for any further tests. Close it and continue testing in a new one.



EXPECTED OUTCOME:

Compare time spent for cache loading by bitbake between steps 4) and 6) . During step 6) it should be much shorter.

ACTUAL OUTCOME:

There's not significant difference between the first and the second executions. After running the script, it goes to immediately start parsing the recipes and then preparing and executing the tasks. There doesn’t seem to be any cache loading at any time either with the first or second machine setup.

I also tested by first running oe-init-build-env instead of the resident version and the behavior was pretty similar: with no significant difference, except than on the non-resident version the execution was even faster by 1 or 2 seconds.

I have attached a log with 4 timed executions exemplifying the case.
Comment 1 Jair Gonzalez 2017-02-07 23:43:42 UTC
I tested again with 2.3_M2 rc3 (226a508da955439b881b2f0a544a3aee76e59919) and the behavior is still the same.
Comment 2 Jair Gonzalez 2017-02-20 16:20:46 UTC
This behavior is reproducible on 2.2.1 rc1 (6a1f33cc40bfac33cf030fe41e1a8efd1e5fad6f), so it's necessary to back-port the fix once it's completed.
Comment 3 oscar lopez arandas 2017-03-23 23:36:49 UTC
Created attachment 3668 [details]
cache reload test log
Comment 4 oscar lopez arandas 2017-03-23 23:39:04 UTC
The behavior is still reproducible on 2.3 M3 rc1.
Comment 5 Richard Purdie 2017-03-29 07:21:19 UTC
I believe the test case was incorrect, I've changed the test case to correctly document how to test the cache reload overhead.