On Sun, Oct 11, 2026 at 07:17:03PM +0200, Helmut Grohne wrote: >... > On Sun, Oct 11, 2026 at 05:08:50PM +0200, Aurelien Jarno wrote: >... > > 1) Avoid an OOM on a typical developer laptop with a lot of of cores, > > but not that much memory, especially given there are many other > > processes running. In that case we the number of jobs should really > > determined from the maximum memory used by a single process during the > > build. > > Given that I build very many packages locally (and some OOM), this > definitely is a use case I had in mind. > > Note that Santiago Vila has been initially using quite small VMs for his > archive rebuilds and encountered quite some failures that way.
Santiago also tried hard to make FTBFS on single-core RC, claiming this would be important for users doing QA work. > I'd like > us to not only consider Debian's buildds as relevant machines for > building but making builds just work locally such that users are enabled > to easily modify packages. The result of the single-core discussion was that anyone rebuilding packages has to be as close as possible to the specs of our buildds. 2-4 GB RAM / core might be a reasonable default setting for --max-parallel for anyone aiming at touching random packages on a machine with insufficient RAM. > > 2) Optimize the build time by limiting the use of swap for active > > processes. In that case the amount of memory is just a typical maximum > > usage. We accept that some gcc/g++ process will just use swap if it > > still improves the overall build time. This is what we used on the > > buildd so far, they have enough swap that an OOM is almost impossible > > (at least for the official buildds). > > This is not a use case I had in mind, but it sounds sensible to me. Note > that when you get to a point where compilers are being swapped, you > typically already swapped out all of tmpfs. I guess my own machines > simple have insufficient swap. On a system with 32GB swap a fair number > of packages stopped building about three years ago. 64GB swap likely is > insufficient today. Does that match your numbers? >... More interesting would be the amount of RAM per core. The i386 buildd where vtk9 has this near-linear scaling has 6 cores and AFAIR 12 GB RAM. 2 GB RAM / core is in my experience a bit tight for building software, especially when it's not a 32-bit architecture like i386 where the address space cannot be more than 4 GB per process. > I have to admit that I'm not quite sure where to go from here. Quite > evidently, the model that I used is too simplistic and the way it is > being used in Debian causes harm to riscv64. I'm sorry about that. >... riscv64 is just the tip of the iceberg, because it currently has no margin of error for build times. Similar to your sqlite3 example, vtk9 taking 4:50 hours instead of 1:45 hours on i386 alone is not a big issue. A general pattern of doubling the build times of large packages would be a problem for all release architectures. If guess-concurrency was used in a way that doubled the build time of chromium, then we'd immediately need more x86 buildds. > Thanks for bearing with me > > Helmut cu Adrian
