[From nobody Fri Oct 23 05:51:06 2026 Received: (at 1149923-done) by bugs.debian.org; 23 Oct 2026 04:49:55 +0000 X-Spam-Checker-Version: SpamAssassin 4.0.1-bugs.debian.org_2005_01_02 (2024-03-25) on buxtehude.debian.org X-Spam-Level: X-Spam-Status: No, score=-113.5 required=4.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FROMDEVELOPER, HAS_BUG_NUMBER,PGPSIGNATURE,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY, USER_IN_DKIM_WELCOMELIST autolearn=ham autolearn_force=no version=4.0.1-bugs.debian.org_2005_01_02 X-Spam-Bayes: score:0.0000 Tokens: new, 12; hammy, 150; neutral, 172; spammy, 0. spammytokens: hammytokens:0.000-+--Hx-spam-relays-external:sk:stravin, 0.000-+--H*RT:sk:stravin, 0.000-+--Hx-spam-relays-external:311, 0.000-+--H*RT:311, 0.000-+--H*RT:108 Return-path: <aurel32@debian.org> Received: from stravinsky.debian.org ([2001:41b8:202:deb::311:108]:47758) by buxtehude.debian.org with esmtps (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.96) (envelope-from <aurel32@debian.org>) id 1xK7E4-00Cs6n-1D for 1149923-done@bugs.debian.org; Fri, 23 Oct 2026 04:49:55 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debian.org; s=smtpauto.stravinsky; h=X-Debian-User:In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=zys2HtYb4Y3kQfIBgUcCqRnye6JuHhWnRcflMt3lVak=; b=q5EXPwqGa/kn09LMXp3Ec0ZC/g 3OkVzXMcg3V4iOZdcZjGxASgE88aecTAgujwp3MS8EBPDQVuOPXnbKSOLJrMQcsup/yaXzlbklLDJ i9GyEJbHDadhGazGwYDcf/U1haNSCbaW7osrFfYNbtpUrB7slA+y6PEVdjcbTO6Y6cAsikRENX/Sn mpZhlSsKIZH9GLlL+lWOJ/FP3KjoKydeIsAVVYMvBPFvzdRYdgZbfvTz90boYh3gcVEyVWGPqEwbp oLXMfVZDrF8YtoBP8u0DaZasxQGsVwjWCVcZ5sVo/zcelqcetFMqyk4OtSfOhEmC9rur53PF8wfqF aDf+HOKg==; Received: from authenticated-user by stravinsky.debian.org with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.96) (envelope-from <aurel32@debian.org>) id 1xK7E2-002w3K-0k for 1149923-done@bugs.debian.org; Fri, 23 Oct 2026 04:49:54 +0000 Received: from authenticated user by hall.aurel32.net with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from <aurel32@debian.org>) id 1xK7E0-0000000EsnT-027L; Fri, 23 Oct 2026 06:49:52 +0200 Date: Fri, 23 Oct 2026 06:49:50 +0200 From: Aurelien Jarno <aurel32@debian.org> To: Maximiliano Curia <maxy@gnuservers.com.ar>, 1149923-done@bugs.debian.org Cc: Adrian Bunk <bunk@debian.org> Subject: Re: Bug#1149923: vtk9: Please consider reducing --require-mem for guess_concurrency to 3.8G Message-ID: <atrnaiE2xdjI_Dza@aurel32.net> References: <179111031454.1236482.9024568909533873428.reportbug@ohm.local> <asucmhnxZMoEWA81@localhost> <179111031454.1236482.9024568909533873428.reportbug@ohm.local> <as1SiPqc5sGKXaXY@hecuba.gnuservers.com.ar> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="xxz9980LrGe/6BWV" Content-Disposition: inline In-Reply-To: <as1SiPqc5sGKXaXY@hecuba.gnuservers.com.ar> User-Agent: Mutt/2.4.1 (2026-07-04) X-Debian-User: aurel32 --xxz9980LrGe/6BWV Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On 2026-10-12 23:35, Maximiliano Curia wrote: > =C2=A1Hola Adrian! >=20 > El 2026-10-11 a las 17:26 +0300, Adrian Bunk escribi=C3=B3: > > I'm raising the severity to serious: > > This change has increased the build time on the slower riscv64 buildds > > from 4 days to 6 days, it has to be reverted. >=20 > I wasn't aware that a build taking longer than before is an RC bug, but > I agree that we should work on this issue and fix it as soon as > possible. >=20 > > Given the near-perfect scaling of a 2.76x build time increase on the > > same i386 buildd where this guess-concurrency use reduced the number of > > cores used by a factor of 3, even 2G would likely still harm build time > > on some architectures. > >=20 > > It is harmful to use guess-concurrency unless: > > 1. it is fixing an actual problem that has been observed, and > > 2. the numbers have been properly measured and not just guessed >=20 > I only added guess-concurrency after running into OOM issues over and > over while working on the vtk9 package. This happened both on my local > machine and on the debusine builders I was using to test, because in > both cases there were a high number of processors and not as much memory > as the build required (in my case it was 16 processors and 64 GB of > RAM). >=20 > So, it is indeed fixing an actual problem. >=20 > You can see that the package that was uploaded to experimental didn't > manage to build on riscv64 and it's almost certainly for this reason > (when the build dies due to OOM there are no logs left behind to > actually verify this). >=20 > Now, regarding the measuring, it's true that in the package I uploaded > to unstable I had added a ballpark estimation and that I didn't take > into account that it would be a very different number for 32bits. I have > now taken a much more accurate measure and I've found that: >=20 > - In 64bit architectures, the maximum amount of memory that a single > process takes is slightly over 6 GB. - In 64bit architectures, the > time-weighted average amount of memory is 1 GB. > - In 32bit architectures, the maximum amount of memory is slightly over 2= GB > - In 32bit architectures, the time-weighted average amount of memory is 5= 50 MB. > - In both cases, the memory consumption is quite skewed, some processes > take very little memory and very little CPU time, while others take a > lot of memory and time. >=20 Thanks for doing that. The above changes combined to the fix done on the=20 guess-concurrency side (#1149922), 4 jobs are used again on the riscv64=20 build daemons. There is still less jobs than before used on amd64 and=20 i386, but the resulting build time is comparable. I am therefore closing the bug. Regards Aurelien --=20 Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://aurel32.net --xxz9980LrGe/6BWV Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEUryGlb40+QrX1Ay4E4jA+JnoM2sFAmra52oACgkQE4jA+Jno M2sXKQ/+PxOzjVvMsqRGrwsAlkcJQQ02bNaZl8boXDgnVpB4gmrM3BbpiIjdKzTX WvDzQPTYC+Vctz5MbSJfyfpKBlZvQjDyAzng8W0b7HjuBy18DF8sT2+/vAn/Dc6i 9+E/HX2GDngfRGhyjDv4rGqWK0NeSZKf7tTLXDSwN4NEd0EDh69UFcWJgxRkLwpk cwnpdLB+G4Et18cZiQWixBghXlT8MF7B+MaVSuAtk4bXEg1pnV87J08y6tXMwJjl O5zo0oMusB7AL4YJ2rfe63jUtTbblb+hnEpXfEbqsUW2DhZV5VDM8HOko6hscJUA v2f610MG/7pJ7ktpje3hFb9GT3lgy1Dc7KV/wLUx9WtI4k1MZZwSY+7WdhDQ64Vp 3cqSA9yawIQPZiBjv5wymBliXS13HY0XEenWj094y2daNFTvh3241j0Gu1RDNP4P tSCm6IaSCF61Ixbc50e9Ng+p7TOl9LsiVaVskeHzKJO9jbj7pVizpmWki01EBDGT JVZSfVey35/0su/PqKTJioNLBgSjkNNzGGz3WqbylMYl0WIa7x3NwpM49uvD5Sj2 mYpJIWOPvz4b5Qbe/NgbJs71eLiKFyJxGetYAbI7+knKuGop8+DJNYIyZrdpKUli PaI1q1/ceX1yGxiKZmhYRgrd1QcFd1DVsDsAY0eA2nIsETYTLbQ= =f2AY -----END PGP SIGNATURE----- --xxz9980LrGe/6BWV-- ]