[bitbake-devel] [PATCH] runqueue: Add output for -S option for listing the changepoints compared with an sstate cache
martin.jansa at gmail.com
Fri Jan 10 14:14:17 UTC 2014
On Wed, Jan 01, 2014 at 11:38:01PM +0000, Richard Purdie wrote:
> So can we find the "least delta" fast? Its not actually that hard
> computationally or on resources, at least in the experiments I've made.
> We know the hashes of the current target's tasks and we can quickly tell
> which are in the cache and which are not (using the same function sstate
> uses for that purpose).
I've finally got some numbers to support my claim that it "feels" slower
with this added functionality.
My script is calling
openembedded-core/scripts/sstate-diff-machines.sh --machines="qemuarm qemux86 qemux86copy" --targets=world --tmpdir=tmp-eglibc/;
which in turn runs
bitbake -S world
three times (once for each machine).
The script on jenkins doing world builds is completely crazy (I've
killed it in last run assuming it was stuck, but it wasn't just terribly
Running 21 hours already and doing 2nd machine from 3 (maybe because
longer SSTATE_MIRROR?). There is one python process using 100% cpu.
In local builds without SSTATE_MIRROR it's not so bad, but still
significantly slower with each release (dylan-dora-master).
Master builds have that WIP patch included in order to finish.
It's not very accurate, because it was running on my desktop and each one has
different metadata, but at least the layers included are similar (only
systems which got separated in dora and removal
of meta-webos-backports which isn't needed for dora and newer).
At least I've executed each test twice.
Martin 'JaMa' Jansa jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: Digital signature
More information about the bitbake-devel