Maybe we should add an additional bot to each config so we have two. Looks like they were busy running 3-hour jobs.

This CL caused the long jobs: https://codereview.chromium.org/1813913003
It's a change to smoothness. There are just a lot of smoothness benchmarks, so those CQ runs take a long time. So other things we can do are to split up smoothness, or use some other kind of static analysis to narrow down the benchmarks we run.

Or maybe we can use swarming to parallelize the load!

Sorry, to clarify, the problem I'm thinking about is not the timeout while waiting for a job to start, but rather the CQ latency from the start of a job to the finish.

Yeah, I think we have better chance using swarming the load rather than a static analysis approach.

Actually swarming is still a WIP for Android, and that doesn't fix the fact that we still need a lot of hardware to run the test. I think we may have better chances forcing people to write 1 benchmark class per file (this is relatively easy to make a PRESUBMIT). For benchmarks that are related, people can group them using package.

So smoothness.py --> smoothness/smooth_top_25.py, smoothness/smooth_foo.py, smoothness/smooth_bar.py


cc other tools/perf owner, any thoughts?

*Retitle the bug title & downgrade the priority since I decided to go ahead with  issue 595744  without waiting for this.