rustc: mark compileprocess as timeconsuming

[mrVanDalo]

Motivation for this change

Hydra is failing to build rustc, because of timeout: https://hydra.nixos.org/build/87373242

@grahamc @Mic92

[grahamc]

LGTM

[Synthetica9]

Not against staging?

[Mic92]

I am confident, that it won't break x86_64 and a good portion of these packages are not built at the moment on aarch64 because rustc timeouts.
Would hydra also would read the value from passthru?

This seems to be a property of the underlying derivation instead:

https://github.com/NixOS/nix/blob/master/src/libstore/parsed-derivations.cc#L88

[vcunat]

@edolstra, @grahamc: this is a problem for darwin on Hydra.nixos.org. I believe we want to add "big-parallel" to "supportedFeatures" of "bigmac-guest". I thought this would be configured in https://github.com/NixOS/nixos-org-configurations but apparently it isn't.

[LnL7]

I don't think rustc is particularly heavy to build compared to other compilers, this looks like a build that actually got stuck.

[vcunat]

Well, even in case we unmark rustc, I believe we'd better have at least one darwin machine with the flag.

[vcunat]

I personally think we might utilize this or similar annotations a bit more and in future it could be better utilized by the runner. It's quite some difference: start a dozen compiler builds on a machine at once or a dozen simple builds. It commonly happens in practice that we rebuild many versions of ghc at once (for example). It may cause issues with RAM as well, especially if many of those builds don't respect system load (though we might be able to fix that by cgroups). Perhaps if we found a good way around almost all the problems without using explicit annotations...

[grahamc]

Vladimir please get on IRC :)

…

Sent from my iPhone

On Feb 7, 2019, at 07:10, Vladimír Čunát ***@***.***> wrote: I personally think we might utilize this or similar annotations a bit more and in future it could be better utilized by the runner. It's quite some difference: start a dozen compiler builds on a machine at once or a dozen simple builds. It commonly happens in practice that we rebuild many versions of ghc at once (for example). It may cause issues with RAM as well, especially if many of those builds don't respect system load (though we might be able to fix that by cgroups). Perhaps if we found a good way around almost all the problems without using explicit annotations... — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[vcunat]

For reference, now hydra.nixos.org does have darwin builders with "big-parallel" flag, so the builds proceed again.