| 2 Apr 2025 |
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 |