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. --
- 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
I've got a prototype implementation of parallelized cross-testing of GCC that I'm happy with using rsh_prog and rcp_prog dejagnu wrappers:
General observations on dejagnu cross-testing process: - All communication with the target is done by Dejagnu via rsh_prog and rcp_prog hooks. These are normally defined to ssh and scp respectively. - Dejagnu copies every testcase to /tmp/ on the target with scp. - Dejagnu executes every testcase via ssh off target's /tmp/. In total there is 1 scp and 3 ssh invocations per testcase.
The idea of below scripts is to assume shared filesystem between host and a pool of target boards, and skip copying executables to target's local filesystem. Since there is no longer local state (local state == contents of /tmp) on the target boards, testcases can be executed on any of the boards in the pool. This happens transparently to dejagnu: dejagnu issues "rsh_prog chromebook-pool ./test" and then rsh_prog converts this to "ssh chromebook-XX ./test", where XX chosen at random.
Script implementation notes: - For some unholy reason there is no way of correctly parse command line from dejagnu and give it to bash. The reason why myssh script ssh'es onto host itself is because that's the only way I've found to reliably execute the command. Hey! The command line was intended for ssh anyway! - Myssh script translates hostname of foobar-pool-01-03-08 into foobar01, foobar03 or foobar08 chosen at random. If there is no "-pool-" mentioned in hostname, then it is used verbatim.
-- Maxim Kuvyrkov www.linaro.org
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
-- Maxim Kuvyrkov www.linaro.org
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.
linaro-toolchain@lists.linaro.org