Hi Adrian and Helmut, On 2026-10-10 18:38, Adrian Bunk wrote: > "not typically" or "not ever"? > > A semantic problem with guess-concurrency is that it is not clear > whether it is supposed to estimate typical maximum usage, or whether > it is supposed to set a hard maximum.
I think most of the confusion comes from here. I see two main use cases: 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. 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). It is not fully clear what use case guess-concurrency is designed for. I would say for the scenario 2, given it doesn't take the swap into account (except for backing tmpfs with the change in git) and it returns 1 instead of failing if requiring more memory than available. I then looked at a practical case, the vtk9 package. It makes almost 11000 calls to gcc/g++ with an average of 215 MiB, and a median of 171 MiB. Only 22 calls use more than 2GiB and only 3 calls use more than 4 GiB, with a maximum of 6.1 GiB. In the scenario 1) we probably want to compute the number of jobs using 6.1 GiB, while in the scenario 2) we probably want to compute the number of jobs using 2 GiB or less as the gain of doing most of the build with more jobs it not lost by *possibly* running a few big jobs in parallel. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B [email protected] http://aurel32.net
