ulf.samuelsson at atmel.com
Tue Mar 17 17:28:27 CET 2009
>>> The Core i7 has 4 cores and each core has two virtual CPUs so the system
>>> sees 8 CPUs.
>>> I saw some commone from someone claiming that if
>>> you have n CPUs, then Buildroot should use make -j`2*n`.
>>> I thought about this, and came up with the following explanation.
>>> If you have one job per CPU, then whenever you have to wait for the
>>> harddisk, you stall this CPU.
>>> If you have several jobs per CPU, then you can gain some time
>>> by running the second job while the first job was waiting for the hard
>>> Whether this works in practice, I cannot say, but it would be
>>> to have some real proof.
>> First of all, I believe -j`2*n` is very agressive. I've seen other
>> of using -j`n+1` or -j`n+2`.
>> Second, your Core i7 still has 4 real cores. Even though HyperThreading
>> presents each core as 2 virtual ones, those are not real 8 cores. And
>> according to , sometimes using HyperThreading may degrade the overall
>> So, you should experiment with your settings and find a sweet spot, which
>> maybe somewhere between 4 and 16 threads :)
> Yes, I know,
> Maybe it is a good idea if the result of a build is published somewhere,
> so that others do not have to go through this process.
> Right now, openembedded does not even build for me,
> since the native perl build fails :-(
>>  http://en.wikipedia.org/wiki/Hyper-threading
I now managed to build the Angstrom image for the AT91SAM9263 by applying
a few fixes present in the ulf/linux branch.
(Did not load on H/W yet though)
perl-native was "fixed" by not building the library which crashed.
libtheora was fixd, not to use docs/examples.
busybox updated to 1.13.3
u-boot, gpsd was set to PARALLEL_MAKE = ""
u-boot updated to 2009.01
Building with PARALLEL_MAKE & Multiple threads was not smooth.
The build crashed several times, due to erros
caused by parallellism. "gettext", "gpsd" and "u-boot" were culprits.
u-boot is NOT built cleanly, even after PARALLEL_MAKE was set to "".
The actual compile completes and generates an u-boot.bin
but this is not deployed to the result directory.
There are logs for different stages, but after the compile, they exist, but
If I remove all the stamps and "bitbake -b <u-boot>" afterwards
then the build completes correctly, and there is an u-boot-at91sam9263ek.bin
in the result directory.
Can it be so, that a stage is started, before the previous stage has been
BTW: The total buildtime was around 2 hours. There is some overhead
since the build was restarted 3-4 times, and local.conf was changed once.
I started the build with PARALLEL_MAKE = "-j2" and BB_NUMBER_THREADS=8.
I noticed that having a lot of threads helps most of the time,
since the CPUs were executing at max frequency.
When the cross compiler, was built,it was different,
most of the cores were not used with this configuration.
2-3 max while compiling gcc.
Maybe the best approach is to build the Angstrom in several stages
with different settings for parallelism.
More information about the Openembedded-devel