Bug 10983 - [Test Case 810] Avoid cache reload for incremental development using a backgrounded bitbake server
Summary: [Test Case 810] Avoid cache reload for incremental development using a backgr...
Status: RESOLVED FIXED
Alias: None
Product: BitBake
Classification: Build System, Metadata & Runtime
Component: bitbake (show other bugs)
Version: 2.3
Hardware: x86 Multiple
: Medium+ normal
Target Milestone: 2.3 M4
Assignee: Richard Purdie
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2017-01-27 17:20 UTC by Jair Gonzalez
Modified: 2017-03-29 07:21 UTC (History)
3 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: Don't know


Attachments
bitbake_memres_vs_nonres.log (8.21 KB, text/x-log)
2017-01-27 17:20 UTC, Jair Gonzalez
no flags Details
cache reload test log (3.82 KB, application/octet-stream)
2017-03-23 23:36 UTC, oscar lopez arandas
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
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.