Hi Helmut, On 2026-10-04 19:04, 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.
While that's definitely an improvement, it's only a small improvement. For a typical buildd with 16GB of RAM, if a package consists in 1GB of source files, requires 4GB of build-dependencies installed in a 1GB chroot, this reduces the available memory size as guessed by guess-concurrency from 16GB to 13GB instead of 16GB to 10GB. At the end it still increases the package build time, and results in an inefficient use of our buildd hardware. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B [email protected] http://aurel32.net
