Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chromium: increase parallelism on aarch64 #78347

Conversation

thefloweringash
Copy link
Member

Motivation for this change

The chromium build on hydra for aarch64 is regularly timing out after two days. With the current configuration of nix.buildCores = 2 and the chromium parallelism limit halving that, it's being run on a single core of the 32-core builder.

Opening as a draft for discussion, since reconfiguring the builders to use more than 2 cores per build might be justifiable if we assume most software will make good use of them.

cc @grahamc

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Ensured that relevant documentation is up to date
  • Fits CONTRIBUTING.md.

@vcunat
Copy link
Member

vcunat commented Jan 23, 2020

buildCores = 2 seems a bit excessive to me, but in any case the combination of these two is very bad. There are also a few other packages that often time out on aarch64 Hydra, e.g. ghc.

If we were going for minimalistic chromium changes, perhaps I'd do

-($NIX_BUILD_CORES+1) / 2
+ $NIX_BUILD_CORES/2  + 1

(regardless of platform). This function seems to have a bit more suitable properties.

@L-as
Copy link
Member

L-as commented May 25, 2020

@vcunat is it because ghc takes so much time (on aarch64) that it's only built on the release channel, and not the unstable channel? I've been trying to use ghc on aarch64 lately and noticed that I have to compile all ghc-related packages myself.

# the 2 day limit.
"-j$NIX_BUILD_CORES -l$NIX_BUILD_CORES"
else
# Build paralelism: on Hydra the build was frequently running into memory
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unrelated nit: while we're here it might be worth fixing the paralelism typo to parallelism

@vcunat
Copy link
Member

vcunat commented May 25, 2020

@L-as: no. Taking lots of time does often cause failures and that's easier to handle by manual restarts on stable branch due to having much fewer ghc rebuilds, but the difference is in ghc version which blows size over our limit. See this ticket: #66277

Even on unstable/master you can still use binaries for lower version of ghc: https://hydra.nixos.org/job/nixpkgs/trunk/haskell.compiler.ghc865.aarch64-linux (but basically no haskellPackages with it are in cache, I think, due to not being default version anymore)

@thefloweringash
Copy link
Member Author

This issue was to solve a particular problem with the aarch64 build timing out, which is no longer a problem so I will close this. There's a new issue for discussing this logic in #100486.

@thefloweringash thefloweringash deleted the chromium-aarch64-parallelism branch October 16, 2020 02:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants