[poky] sstate status

[Tian, Kevin]

>From: Gary Thomas [mailto:gary at mlbassoc.com]
>Sent: Monday, December 06, 2010 7:16 PM
>
>On 12/05/2010 05:02 AM, Gary Thomas wrote:
>> On 12/05/2010 04:19 AM, Tian, Kevin wrote:
>>>> From: Gary Thomas
>>>> Sent: Saturday, December 04, 2010 8:48 PM
>>>>
>>>> On 12/03/2010 04:31 PM, Gary Thomas wrote:
>>>>> On 12/03/2010 09:34 AM, Paul Eggleton wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> I've been doing some tests with sstate, and I've managed to get to a
>>>>>> stage where I can share the SSTATE_DIR between my two machines (one
>>>>>> running Fedora 14 and the other Kubuntu 10.10) and almost get a
>>>>>> successful build from a clean TMPDIR. My last test got to
>>>>>> poky-image-minimal.do_rootfs and then failed due to some kind of
>>>>>> package dependency issue:
>>>>>>
>>>>>> --------- snip ---------
>>>>>> | Processing rpm...
>>>>>> | Processing zypper...
>>>>>> | error: Failed dependencies:
>>>>>> | elfutils>= 0.148 is needed by rpm-5.1.10-r7.i586
>>>>>> | libaugeas0>= 0.7.3 is needed by
>>>>>> zypper-1.4.7+git0+9eb0e248e06c8d20ad054be2439149d9ede37531-r1.i586
>>>>>> | ERROR: Task failed: ('function do_rootfs failed',
>>>>>>
>>>>
>'/home/pokystuff/tmp/work/qemux86-poky-linux/poky-image-minimal-1.0-r0/temp/log.
>>>> do_rootfs.6874')
>>>>>>
>>>>>> --------- snip ---------
>>>>>>
>>>>>> A "bitbake -c clean augeas elfutils" and then "bitbake
>>>>>> poky-image-minimal" again went through OK (and built the
>>>>>> aforementioned recipes from sstate) , so I'm not sure what went wrong
>>>>>> here.
>>>>>>
>>>>>> My current state of work is in the paule/sstate contrib branch, which
>>>>>> is based on Kevin's tk/sstate branch. Kevin, I think the sooner we can
>>>>>> move this towards master the better, then we can get some wider testing.
>>>>>>
>>>>>> FYI Joshua has made bug #507 into a tracking bug for current sstate
>>>>>> issues:
>>>>>> http://bugzilla.pokylinux.org/show_bug.cgi?id=507
>>>>>
>>>>> I gave this a simple try and it failed miserably. Working from a copy of
>>>>> Paul's branch in poky-contrib, here's what I did:
>>>>>
>>>>> * On machine A (x86 Fedora 11)
>>>>> % bitbake poky-image-minimal
>>>>>
>>>>> * On machine B (x86 Fedora 13)
>>>>> -- Copy sstate-cache from machine A to /tmp/sstate-cache (rsync with
>>>>> all perms& timestamps preserved)
>>>>> -- Using the identical conf/local.conf file from machine A, except
>>>>> I set up SSTATE_MIRRORS like this
>>>>> SSTATE_MIRRORS ?= "\
>>>>> file://.* file:///tmp/sstate-cache/"
>>>>> % bitbake poky-image-minimal
>>>>>
>>>>> Fell apart pretty badly. Look at the output
>>>>> http://www.mlbassoc.com/poky/poky_with_sstate.out
>>>>>
>>>>> Also, it seemed to be rebuilding a lot of packages. IMO, there's
>>>>> no reason it should have to rebuild _any_
>>>>>
>>>>
>>>> One thing that seems to be significant is the base build directory path.
>>>> In the case above, they did not match, i.e.
>>>> * On machine A, BUILDDIR=/tmp/sstate_testing
>>>> * On machine B, BUILDDIR=/home/local/my_sstate_test
>>>> I tried it this way as it matches my [customer's] expected usage.
>>>
>>> I think in usual case the directory paths would mismatch. So let's stick to that
>>> configuration to expose more issues. In my previous debug, I have made it
>>> in a good shape but would now turn to RP's branch to try more experiments.
>>>
>>> It would be good if you also try that one:
>>> http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/log/?h=rpurdie/tweaks2
>>>
>>>>
>>>> I've rerun the experiment again where I used identical paths on both
>>>> machines and the results were vastly improved. It still takes a horrible
>>>> length of time (64 minutes on a fast 4 processor box) and rebuilds way to
>>>> many packages for just replaying what's already been done though (IMO).
>>>> Results are at
>>>> http://www.mlbassoc.com/poky/poky_with_sstate_same_paths.out
>>>>
>>>
>>> In my run ~25min are consumed just for sstate check/installation on a NHM 4-core box.
>>> then several minutes for rootfs generation if two builds totally match. the slow sstate
>>> phase comes from same reason as a slow build - the 'exec' overhead. I use 'sato' as
>>> the target.
>>>
>>> In your case, however there're still some packages rebuilt, such as gzip-native,
>>> unifdef-native, eglibc-initial, ncurses, etc. and also gcc related packages are rebuilt
>>> which just consumes time. Has your source tree changed between the two builds?
>>
>> No, identical source trees for all three runs.
>>
>> I'll try it again later today with Richard's tree.
>>
>
>I've now rerun this with Richard's tweak2 changes, building in completely
>different tree paths.  While it did work, I don't see the point as it took
>even longer the second time (using the sstate cache) and generated just as
>much work :-(  Something is still not working as desired.
>
>Original 'bitbake poky-image-minimal' into /tmp/sstate_testing
>   time - 111 minutes
>   space - 22.9 GB (in tmp)
>
>Rerun, using the sstate-cache from the first run
>   time - 114 minutes
>   space - 21.7 GB
>
>I think this last line from the rerun test is telling:
>   NOTE: Tasks Summary: Attempted 1621 tasks of which 282 didn't need to be rerun and
>0 failed.

I have " Attempted 1621 tasks of which 953 didn't need to be rerun and 0 failed."
It should come from the fact that I use same source directory this time. I have one fix
for difference source tree in my previous branch, which is still under discussion with RP
and not in RP's branch yet. So sorry for inconvenience. I should raise the info earlier.

Although that, I took a quick look of my build. The thing is a bit weird. It's similar to
your previous result with Paul's branch, that many recipes are rebuilt though they're
claimed to be accelerable, such as gzip-native, unifdef-native, etc. The result is that
new sstate packages are generated to simply override old one. They DO have same
checksum because only one version exists with new timestamp.

I didn't look into recent commits yet. It looks that the checksum calculated at setscene
stage is different than the one finally written into sstate package.

Thanks
Kevin