| 2 Apr 2025 |
 Grimmauld (any/all) | will slow on the aarch64 though | 20:54:50 |
| Grimmauld (any/all) | Sorry! | 20:55:08 |
 Gaétan Lepage | 
Download clipboard.png | 20:55:09 |
 emily | you want cores × jobs < nproc always although when multiple people are using them that pretty much has to be divided by that | 20:55:31 |
| Grimmauld (any/all) | when i started this work it was completely idle | 20:55:33 |
| emily | thankfully the AArch64 one has so many cores that you can probably just pick something conservative and still have it finish faster than anything else would :P | 20:55:45 |
| emily | no worries. it's hard to load balance | 20:55:56 |
 Ihar Hrachyshka | I do 1 job and 20 cores on aarch64 but it's pytorch... | 20:55:56 |
| emily | and sorry again to Gaétan Lepage for the dodgy grep :) | 20:56:04 |
| Gaétan Lepage | Ideally we would need a scheduler like SLURM for those shared systems | 20:56:07 |
| Grimmauld (any/all) | thats exactly why i am building all those packages on aarch64-linux, it just is the fastest builder | 20:56:13 |
| Gaétan Lepage | In reply to @emilazy:matrix.org
and sorry again to Gaétan Lepage for the dodgy grep :) Fair enough, I have been the culprit quite a few times in the past ! | 20:56:30 |
| Ihar Hrachyshka | yeah I was thinking it's weird that we have to pick numbers for whole nixpkgs-review run when it really depends on whether others need the machine... | 20:56:49 |
| Grimmauld (any/all) | (i also hjonstly didn't expect to be able to overload the darwin machine just feeding single build jobs by hand...) | 20:56:57 |
| Grimmauld (any/all) | * (i also honstly didn't expect to be able to overload the darwin machine just feeding single build jobs by hand...) | 20:57:02 |
| Grimmauld (any/all) | * (i also honstly didn't expect to be able to overload the aarch64-linux machine just feeding single build jobs by hand...) | 20:57:10 |
| emily | the default is jobs = cores = nproc | 20:57:20 |
| emily | so as soon as two builds with >80 parallelizable C compiles happen it blows up | 20:57:40 |
| emily | (and it'll try to do 80 builds if it can, so very easy to go over) | 20:57:51 |
| Gaétan Lepage | The current SotA for this kind of use is ver sub-optimal | 20:57:59 |
| emily | https://github.com/NixOS/nix/pull/11143 would make this a lot less painful | 20:58:05 |
| emily | since it would stop more build jobs spawning with some common build systems when the load is already too high | 20:58:23 |
| emily | but there's been like 3 PRs adding this to Nix and crickets so far | 20:58:32 |
| emily | (it used to be in stdenv but it got removed because it slowed throughput for Hydra) | 20:58:40 |
| Grimmauld (any/all) | wouldncouldn't we just put that in lix and have the community builders run lix if nix team doesn't hurry up? | 21:01:05 |
| emily | that's not a battle I'm interested in having :P but I have considered posting the patch on the Lix side to get some design feedback | 21:01:53 |
| emily | FWIW, it is not a panacea. e.g., Rust builds don't support it, so those will still chew up endless amounts of CPU. it would help for Make and Ninja and there's probably other build systems that could make use of it too. | 21:02:29 |
| emily | but it would make large builds on workstations or shared machines meaningfully less painful | 21:02:46 |
| Ihar Hrachyshka | nix-daemon could also perhaps be smarter (e.g. throttle new jobs spawns when load is too high) | 21:03:24 |
| emily | yeah, that would be nice | 21:03:42 |
