| 1 Mar 2025 |
Lun | definitely worse: https://gist.githubusercontent.com/LunNova/b1cf007f1af52b4dc353fd9925857b97/raw/63ea9ec1a500d5ef6ad4f2f0eac7a59b6db6e310/huge%2520composable_kernel%2520template%2520instantiation.txt | 16:07:29 |
Lun | The ~4h builds are nix cores config set to 128 on a 64c/128t epyc milan eng sample that's clocking down to <3GHz due to power limits, not sure what the relative speedup per core will be but probably not enough to overcome dropping to 24 build threads.
Does bumping meta.timeout to 20h to start with sound reasonable? | 16:13:51 |
emily | might make sense to do 48 and then scale down based on the actual time | 16:19:08 |
emily | to avoid spending 20 hours on a build that times out and gets thrown away | 16:19:16 |
emily | (I am not on the infra team, don't trust anything I say) | 16:19:34 |
Vladimír Čunát | I believe it's fine to put an unnecessarily big value in there. It's just a single package. I see the main purpose to limit some accidents where resources would be spent continually without bringing value. | 16:23:17 |
Vladimír Čunát | But honestly, doing so much work in a single derivation is rather risky. Generally it's better to split it up. | 16:24:19 |
Vladimír Čunát | For example, sometimes we need to restart the queue runner, i.e. all builds in progress get scrapped. | 16:24:57 |