Hi
Op 13-06-2021 om 02:38 schreef Randy MacLeod:
On 2021-06-12 12:31 p.m., Ferry Toth wrote:
Hi
Op 10-06-2021 om 22:35 schreef Ferry Toth:
Hi,
Op 10-06-2021 om 21:06 schreef Trevor Gamblin:
On 2021-06-10 5:22 a.m., Ferry Toth wrote:
**[Please note: This e-mail is from an EXTERNAL e-mail address]
Hi Trevor,
Gmane is really messing things up here, sorry about that. I need
to create a new thread I'm afraid.
I'd like to your reworked patch.
But note, I reworked it too (but maybe wrongly). I builds like 90%
of my image, but fails building cmake-native. Or more accurately
it fails do_configure while trying to build a small test program.
Hi,
I've pushed the patch onto my fork of the poky repo at
https://github.com/threexc/poky
Let me know how your testing turns out - I am still running tests
as well, but it would be good to know how others' attempts turn
out, and more changes could still end up being necessary.
Your patch didn't apply clean on Gatesgarth, but fix seemd trivial.
With this it builds cmake-native fine, thanks!
You can find it here:
https://github.com/htot/meta-intel-edison/commit/8abce2f6f752407c7b2831dabf37cc358ce55bc7
I will check if any other build errors occurs, and if not will try
to time image build with and without the patch to compare
performance and see if it worth the effort.
It works fine. To measure time I first built
https://github.com/htot/meta-intel-edison (gatesgarth), so everything
needed is downloaded and cached. Then prior to each run I `rm -rf
out` and `rm -rf bbcache/sstate-cache/*` to force everything to
rebuild. And then `time bitbake -k edison-image`
With patch:
real 218m12,686s
user 0m24,058s
sys 0m4,379s
Without:
real 219m36,944s
user 0m24,770s
sys 0m4,266s
Strange, I expected more.
Hi Ferry,
Thanks for the update.
Trevor and I saw similar (lack of ) results.
Trevor even trying getting kea, which uses 'make' to be done the
'configure' stage, for two builds in differect dirs. Then to run the two
'bitbake -c compile kea'
with and with out the patch with the expectation that with the
job server patch and the right number of jobs, the two builds would
take longer. I don't know the exact timing but there was no
noticeable difference.
We did strace things to confirm that the make wrapper was being called
and the actual make was being called by the wrapper. I suspect that
I watched running processes from KDE ksysguard and I believe the number
of compilers was actually restricted with the patch. On the other hand
the server I tried was running munin which logs #processes over time and
there I didn't see a difference. Confused..
the next thing we try will be to patch 'make' to log when the jobserver
kicks in or to play with some make jobserver demo such as:
https://github.com/olsner/jobclient
to get some experience with how things are supposed to work and
to be able to strace a successful use of the job server feature.
I'm available for testing.
A little RTFM / UTSL may also be required.
../Randy
This is on 4 core/8ht i7-3770 CPU @ 3.40GHz with 16Gb RAM and nodejs
restricted to -j 2 (so that alone takes ~ 60min to build).
I do like the jobserver idea a lot. Especially if it would take memory
restrictions into account as well. The problem with building nodejs (and
probably rust as well), there is lots to compile so you really want -j
16. But then during linking ld uses 4GB per instance, and there are 5
started. So on my machine I wouldn't want to start more then 3.
- Trevor
Ferry
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53850): https://lists.yoctoproject.org/g/yocto/message/53850
Mute This Topic: https://lists.yoctoproject.org/mt/82015730/21656
Group Owner: [email protected]
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
