We currently run the EWS for ARMv7 JSCOnly on a x86_64 machine that cross-compiles for ARMv7 and then the tests run on a Raspberry Pi via the --remote-config-file option for run-javascriptcore-tests script This lately was not running very smoothly, as it was taking sometimes too much time to complete the testing. But now we have an ARM server that can do things natively and much faster than we have now. I bench-marked it and it can build JSCOnly in 5 minutes and runs the whole run-javascriptcore-tests also in 5 minutes.
Created attachment 414646 [details] Patch
(In reply to Carlos Alberto Lopez Perez from comment #0) > I bench-marked it and it can build JSCOnly in 5 minutes and runs the whole run-javascriptcore-tests also in 5 minutes. For a clear comparison, can you also state similar timing for current setup. Also, is the plan to do this for other JSC queues as well?
Comment on attachment 414646 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=414646&action=review > Tools/CISupport/ews-build/config.json:589 > + "workernames": ["igalia-jsc32-armv7-ews-02"] This is switching worker only for tester queue, not for builder queue.
(In reply to Aakash Jain from comment #3) > Comment on attachment 414646 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=414646&action=review > > > Tools/CISupport/ews-build/config.json:589 > > + "workernames": ["igalia-jsc32-armv7-ews-02"] > > This is switching worker only for tester queue, not for builder queue. right.. the switch of the builder one is not reflected on the patch, but internally we are switching the machine assinged to igalia-jsc32-armv7-ews
<rdar://problem/71757055>
(In reply to Aakash Jain from comment #2) > (In reply to Carlos Alberto Lopez Perez from comment #0) > > I bench-marked it and it can build JSCOnly in 5 minutes and runs the whole run-javascriptcore-tests also in 5 minutes. > For a clear comparison, can you also state similar timing for current setup. > Current queue builds as fast as this (since it cross-builds on x86_64) but the test step takes 1 hour to run. > Also, is the plan to do this for other JSC queues as well? We are trying to get better hardware to improve also the timings on the MIPS queue, but I don't think it will be fast enough to build WebKit. So very likely we will continue to cross-build for that architecture and continue running tests on the MIPS queue with the --remote-config-file option
Comment on attachment 414646 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=414646&action=review > Tools/CISupport/ews-build/steps.py:1617 > + self.command.extend(['--no-testmasm', '--no-testair', '--no-testb3', '--no-testdfg', '--no-testapi']) what was the reason that igalia jsc-armv7 queue needed these parameters (e.g.: --no-testmasm) earlier, and what's the reason it doesn't need it now? > Tools/CISupport/ews-build/steps.py:1622 > + self.command.extend(['--memory-limited', '--verbose']) why verbose?
(In reply to Aakash Jain from comment #7) > Comment on attachment 414646 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=414646&action=review > > > Tools/CISupport/ews-build/steps.py:1617 > > + self.command.extend(['--no-testmasm', '--no-testair', '--no-testb3', '--no-testdfg', '--no-testapi']) > > what was the reason that igalia jsc-armv7 queue needed these parameters > (e.g.: --no-testmasm) earlier, and what's the reason it doesn't need it now? > Previously the tests were running on a remote board (a Raspberry Pi) and the built-product was copied to the board at the moment of starting the tests. The function responsible of copying this built-product (prepareBundle() at Tools/Scripts/run-jsc-stress-tests) was only copying the jsc binary but not the testmasm, testair, testb3, testdfb, testapi binaries. Now the tests run natively on the same host that hosts the buildbot worker, so no copying of the built-product to a board is involved. > > Tools/CISupport/ews-build/steps.py:1622 > > + self.command.extend(['--memory-limited', '--verbose']) > > why verbose? It gives information about which exact test is running at the time. IMHO the stdout log gives more information that way. It is also how we run the JSC tests on the JSCOnly post-commit bot at https://build.webkit.org/waterfall?category=misc
(In reply to Carlos Alberto Lopez Perez from comment #8) > Now the tests run natively on the same host that hosts the buildbot worker, so no copying of the built-product to a board is involved. The build and test are still on different bots. bot on builder queue builds, upload the archive, and bot on tester queue downloads it.
(In reply to Aakash Jain from comment #9) > (In reply to Carlos Alberto Lopez Perez from comment #8) > > Now the tests run natively on the same host that hosts the buildbot worker, so no copying of the built-product to a board is involved. > The build and test are still on different bots. bot on builder queue builds, > upload the archive, and bot on tester queue downloads it. Right. I think maybe I was not clear enough. I will rephrase what I was trying to mean. - Now both machines are armv7 machines: The build-queue builds natively and the test-queue simply executes the binaries it downloads from the build-queue. - Previously the build-queue was a x84_64 machine cross-building for armv7 and the test-queue was another x86_64 machine that ran the test step remotely on a RPi board via the "--remote-config-file" option for the script run-javascriptcore-tests.
sounds good
Committed r270348: <https://trac.webkit.org/changeset/270348> All reviewed patches have been landed. Closing bug and clearing flags on attachment 414646 [details].