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?
Helmut
