Hi Paul, Paul Gevers, on 2023-12-03: > 8GiB... that's not little, considering that that's what these hosts have as > RAM (https://wiki.debian.org/ContinuousIntegration/WorkerSpecs). […] > ci-worker-arm64-NN: -rw------- 1 root root 3.9G May 27 2022 /swap […] > It's kbytes, memory, ratio == 0, 0, 50 across all our hosts.
Thank you for the figures, that makes:
(50% × 8 GiB RAM) + 4 GiB swap = 8 GiB CommitLimit
With overcommit disabled, that is a hard limit for commiting
anonymous memory for the whole system (which makes me wonder how
come we hit a failures modes which looks like it should only
occur when some overcommit is allowed). 8 GiB is the lower
limit documented by upstream, so I'm even wondering how is it
possible that the test has been passing in the past. Some more
precise calculation of memory consumption show me an upper bound
of 7,900,000 kB, with some runs consuming in the 6,000,000 kB.
This may be explained by the algorithm involving random steps.
Otherwise said, tests may pass on sheer luck…
> Be aware though that tests don't run in
> isolation. At the same time, on our arm64 hosts, one more test might be
> running. So what's *available* might not be constant in time.
Okay, that means there will be concurrent access to an already
tight space for shasta. It looks like that's on me being
greedy. I see what I can do to reduce anonymous maps usage.
Upstream's documentation looks to have a chapter on reducing
memory consumption by giving options to use disk backed memory
maps, although on first try it didn't look to reduce the commit
memory consumption. Let's see if I can get somewhere…
Have a nice day, :)
--
.''`. Étienne Mollier <emoll...@debian.org>
: :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da
`. `' sent from /dev/pts/1, please excuse my verbosity
`- on air: Tangerine Dream - Stratosfear
signature.asc
Description: PGP signature
