On 01/29/2014 01:56 PM, Richard Purdie wrote:
On Wed, 2014-01-29 at 13:09 +0100, Ulf Samuelsson wrote:
We discussed this 2.3 months ago.
Did some studies on my dual hex-core machine (24 H/W treads) while
building a cloud9-gnome-image derivative.
This did about 7500 tasks.
Enabled the CPU supervisors in the panel.
Everything seems to be ok with BB_NUMBER_THREADS = "24" for about 4-4500
tasks.
Then the CPUs are mostly inactive and only 1-2 running for ~500 tasks.
Then parallellism is resumed until about task 7000, and again
only a few CPUs are active.
This is likely whilst the lib and toolchain is getting built.
I believe that some tools use "make" within the Makefile,
and they are written badly, and do not use "-j <n>" for
that part of the build.
Which recipes were building at this point? It would be interesting to
track them down.
I would suspect "recursive" makes. If you use autotools with the evil
"SUDIRS=..." construction, it will WAIT for that dir to finish before
doing anything else.
It's much better to construct a giant makefile in the root, autotools
will happily do that once properly instructed. I've seen first time
builds going from half an hour to two minutes, and incremental builds
taking only one or two seconds instead of several minutes just because I
removed the recursion.
Got my build down to 83 minutes.
Since I have 96 GB of RAM, I tried creating an 80 GB tmpfs for the build,
and copied the download and the recipes to the ram.
That shaved only 2 monutes from the build, and some stuff,
still built using only a single CPU.
That confirms what I have already suspected - it is pointless to buy an
SSD, building OE is mostly CPU limited and hardly I/O related.
I guess the only way to really speed up the build would be to have
multiple machines participate in it. Single machines aren't really
getting any faster.
There are certainly dependency bottlenecks in the build such as the
toolchain, compiler, gettext, gtk+ and so where large numbers of things
need those dependencies to get built before they can proceed. Not sure
what we can do to help this though.
Move them to the front as far as possible I guess. And any package they
depend on as well... It should try to set up the shortest tree to be
able to build the crosscompiler and build that first...
Mike.
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
