Maxim,
On 24 May 2014 07:24, Maxim Kuvyrkov maxim.kuvyrkov@linaro.org wrote:
On May 24, 2014, at 5:10 PM, Maxim Kuvyrkov maxim.kuvyrkov@linaro.org wrote:
Hi,
I have tried out a prototype of using binfmt_misc, and it does not appear to be a worthwhile solution at this point.
Bottom line: with a nice fast multi-core x86 server and a pool of ARM boards we can test GCC in ~20min.
Testing setup:
- Core i3 2-core host
- Chromebook 2-core target, SSD disk
- WiFi network
- GCC mainline built from sources with same flags both natively and cross: C, C++, Fortran.
General observations about testing ARM toolchains:
- When testing natively target is busy 100%: around 50% of time is spent compiling testcases, 40-45% in dejagnu/expect, 5-10% on actual test execution. Target is the bottleneck.
-- 21633.22user 4400.13system 4:13:11elapsed
- With testing cross using standard rsh_prog=ssh, rcp_prog=scp, target is busy 40% of the time: 30% on ssh, 10% on actual test execution. Host is the bottleneck.
--
-- 9093.65user 2574.72system 1:14:28elapsed
- When testing cross (using method below) target is busy only 15-20% of the time: 10% on ssh and 10% on actual test execution. Host is the bottleneck.
-- 9490.16user 2882.54system 1:10:57elapsed
The figures you have given on IRC are even more impressive, this is great!
At some point, if you find that your random function is not adequate, I can share a suggestion: in the past we used distcc a lot, but distcc does not take the actual load of the machine into account (only the # of distcc jobs currently running). I paired it with DMUCS, which spawns a loadavg server on each slave, and gives the name of the least loaded one to distcc. It can be used for anything else than distcc in fact.
So we could probably run the loadavg servers on each board, and have a master answering requests from myssh/myscp, giving the current "best" target.
Christophe.