On Sun, Oct 04, 2026 at 07:04:11PM +0200, Helmut Grohne wrote: > Hi Aurelien, > > On Sun, Oct 04, 2026 at 12:31:06PM +0200, Aurelien Jarno wrote: > > Thanks for providing guess-concurrency, it's a clear improvement over > > the number of open-coded equivalents in many debian/rules file. > > Thank you! > > > That said, I have observed that MemAvailable is sometimes significantly > > lower than expected on some build daemons. I have tracked that to the > > use of tmpfs as the build directory (which by the way is the default in > > sbuild): until the data is flushed to the swap, the corresponding memory > > amount disappears from MemAvailable. This causes the number of jobs to > > be reduced for no real reason (the memory is still be available for > > build), especially for packages with big sources. > > > > Could you please consider using MemTotal instead? I think it represents > > better the amount of memory a build daemon is able to use. > > I see where you are coming from. When designing it, I was considering > that system services (and in case of building on a desktop or laptop) > also user applications may consume RAM. Simply going from MemAvailable > to MemTotal would degrade that use case. An earlier version did use > MemTotal, so it is not clear cut to me just yet. > > It seems like we do want to use some amount of swap, but swapping out > everything might be too much. Can we find a middle ground? > > How about using > > MemAvailable + min(SwapFree, (MemTotal - MemAvailable) / 2) > > as a better approximation? I recognize that this is not going all the > way that you want to go. However, it would still consider min(SwapFree, > MemTotal / 2) as a minimum even if MemAvailable would be fully consumed > with tmpfs. On systems without swap, this would result in the same > behavior as before the change. > > Can you give me an idea of whether that would improve the buildd use > case? Would it be a sufficient improvement in your view?
Let me try to explain the severity of the problem caused by guess-concurrency. IMHO the most important fix would be to make it clear in the documentation that guess-concurrency should only be used when ***really*** necessary. Sometimes guess-concurrency is used with an insanely high value (#1149937), people guessing numbers is just harmful. >From a decade of experience keeping packages alive on 32-bit I can tell that it is usually exactly one ld call or the one compilation of the swig-generated Python bindings for a C++ library that is the memory hog. Using guess-concurrency does not make much sense in this typical case. Packages where the maximum memory usage scales with the number of cores do exist, but they are rare. On 32-bit architectures, requiring more memory per process than the address space available for a process is obviously wrong. In [1] the removal of guess-concurrency in my 9.6.2+ds-2+test1 package uses 6 instead of 2 cores on the buildd, resulting in a 2.76x build time difference. A 2.76x speedup for a 3x increase in the number of cores is as close to perfect scaling as might happen practice. In practice we have to pick one of the following: 1. treat build time increases due to guess-concurrency as RC bugs, or 2. drop riscv64 as release architecture And I mean 2. seriously, [2] increases the build time of a package currently involved in a transition from 4 to 6 days on the slower buildds due to only using 2 instead of 4 cores. Even on the new faster buildds[3] it would likely also push the build time above 2 days. And riscv64 is just the tip of the iceberg: We spent a decade getting parallel builds working in nearly all packages, we don't want to lose a large part of that when people start modifying packages on a large scale with super-high guessed limits to guess-concurrency - requiring in the need for more buildds on multiple architectures. And you also want to be conservative regarding how to calculate the available memory. Not using all cores on a 4-core riscv64 buildd with 16 GB RAM because your proposed formula would use only 3 cores when an uploader used 4 GB as guessed value[4] - that's just bad. Can we agree that guess-concurrency increasing build times is a bad thing that should usually result in an RC bug, or do you insist on killing riscv64? > Helmut cu Adrian [1] https://buildd.debian.org/status/logs.php?pkg=vtk9&arch=i386 [2] https://buildd.debian.org/status/logs.php?pkg=vtk9&arch=riscv64 [3] rv-manda-0{2,4} [4] which seems to be the most common uploader guess
