Increase jumbo_file_merge_limit for the CQ bot linux-jumbo-rel to 50. |
||||
Issue descriptionWe have a bot in CQ to prevent jumbo compilations from breaking. That is the linux-jumbo-rel bot, and it is running with the default configuration for jumbo which implies jumbo_file_merge_limit=8 when goma is available (to get the most benefit out of goma's parallelism). The most common way to break a jumbo compilation is by having two symbols with the same name and same scope in a build target. As long as those two symbols end up in different jumbo chunks it will still look fine though. To increase the chance that two potentially conflicting symbols end up in the same jumbo chunk, and get noticed and caught by CQ, bigger jumbo chunks are better. Locally I'm running with 9999 (an approximation of infinity) which works but has some drawbacks, like bots needing 10 minutes for some compile commands. For CQ I propose increasing the size from 8 to either 50 (the non goma default) or 100 or 200 (for even more compatibility testing but without being 100% similar to the default configuration).
,
Nov 15
I went with 50 in https://chromium-review.googlesource.com/c/chromium/src/+/1337496 9999 would have been my second option but that just doesn't work in goma due to timeouts.
,
Nov 15
,
Nov 16
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/741d5350cfd8223704c90e511f44a03a607f134b commit 741d5350cfd8223704c90e511f44a03a607f134b Author: Daniel Bratell <bratell@opera.com> Date: Fri Nov 16 17:17:32 2018 Have linux-jumbo-rel build with non-goma jumbo chunk size Currently linux-jumbo-rel, the CQ bot, builds with the default jumbo chunk size, and since it uses goma that is 8. Building with relatively small chunks (8) means that it doesn't notice symbol clashes that happen with larger chunks so it's better to build with the non-goma default, 50. This will slightly reduce parallelism of builds, and might trigger more files to be recompiled for changes, but it will also bring along with it the benefits of larger jumbo chunks (less CPU cycles spent per compiled cc file, faster linking) so it's not obvious how it will affect performance, if at all. Bug: 905588 Change-Id: I950ef63093f60580e98891aa0f556fa57b5d6628 Reviewed-on: https://chromium-review.googlesource.com/c/1337496 Reviewed-by: Dirk Pranke <dpranke@chromium.org> Commit-Queue: Daniel Bratell <bratell@opera.com> Cr-Commit-Position: refs/heads/master@{#608822} [modify] https://crrev.com/741d5350cfd8223704c90e511f44a03a607f134b/tools/mb/mb_config.pyl
,
Jan 11
Setting defect without priority to default. |
||||
►
Sign in to add a comment |
||||
Comment 1 by brat...@opera.com
, Nov 15