This is not the point, I think. 

For toolchain testing, specific CPU matters less than for kernel testing. Even less important is which particular board revision or flavour. If the build system is smart and can figure out which CPU it's running (most are), it should make no difference if we run builds on dual-A9, quad-A9 or even A15, as long as it builds and passes the tests.

For instance, fixing Panda-ES on LAVA means I'll wait on a long queue, because there were only a few of them, while the old Panda had 15 idle all the time. They might be slower, but it's much quicker to get results from them than waiting for the ES to free up.

In the past, I have used a language that describes system properties to reserve boards (like "A9 & NEON & RAM >= 1GB") that would give me a list of available boards, when I'd choose one based on my own criteria. So, if you know how long it usually takes to build on X, Y and Z boards, and you have a list of jobs waiting on each one of them, with their own average build times, you can estimate which will be freed first, and list the boards sorted by that order. I could then pick the one I think it's best and add my build to that board's queue.

With the number of different boards going up and the total number of boards in the racks also going up, including virtual machines, I assume this will save a lot of time in the future, even though it looks quite daunting right now to implement.

cheers,

--renato

PS: I've used this system completely automatic for our regressions tests, in parallel by many developers and benchmarks at the same time and it worked a charm.