From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id ED63A138334 for ; Fri, 1 Mar 2019 15:01:53 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9332CE0855; Fri, 1 Mar 2019 15:01:50 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 2D676E0841 for ; Fri, 1 Mar 2019 15:01:49 +0000 (UTC) Received: from 5e46-fe7f-49ff-6ef0-3d80-83ab-07d0-2001.dyn.estpak.ee (5e46-fe7f-49ff-6ef0-3d80-83ab-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:83ab:3d80:6ef0:49ff:fe7f:5e46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: leio) by smtp.gentoo.org (Postfix) with ESMTPSA id C9CDF335C67 for ; Fri, 1 Mar 2019 15:01:45 +0000 (UTC) Message-ID: <0dadab8643587f7e26ee6c4129fce7623389e7a2.camel@gentoo.org> Subject: Re: [gentoo-dev] util-linux build time increase? From: Mart Raudsepp To: gentoo-dev@lists.gentoo.org Date: Fri, 01 Mar 2019 17:01:39 +0200 In-Reply-To: References: <29348cc8-6a3b-3eed-fc72-7b9869c7a4ca@gentoo.org> <1551089256.19496.5.camel@tsoy.me> <1551089881.19496.8.camel@tsoy.me> Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-ziatUhPNLQRu1MDbowGM" User-Agent: Evolution 3.30.5 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 X-Archives-Salt: dd93824a-ed8e-43b7-ae02-0da94d2cce89 X-Archives-Hash: 5abc84e323e0899e233c66ea91c44826 --=-ziatUhPNLQRu1MDbowGM Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =C3=9Chel kenal p=C3=A4eval, N, 28.02.2019 kell 04:13, kirjutas Joshua Kina= rd: > On 2/25/2019 05:18, Alexander Tsoy wrote: > > =D0=92 =D0=9F=D0=BD, 25/02/2019 =D0=B2 13:07 +0300, Alexander Tsoy =D0= =BF=D0=B8=D1=88=D0=B5=D1=82: > > > =D0=92 =D0=A7=D1=82, 21/02/2019 =D0=B2 04:36 -0500, Joshua Kinard =D0= =BF=D0=B8=D1=88=D0=B5=D1=82: > > > > Does anyone have an idea why util-linux's build time would go > > > > up > > > > significantly from 2.32.x to 2.33.x? It may be a MIPS thing, > > > > as my > > > > x86_64 > > > > box shows no discernible change in build times between the same > > > > versions. > > > > Can any other archs check w/ genlop to see if they see a large > > > > jump > > > > in build > > > > time? > > > >=20 > > > > 'genlop -t util-linux' output on my SGI system (some entries > > > > removed > > > > for > > > > brevity): > > > >=20 > > > > Thu Feb 1 11:26:33 2018 >>> sys-apps/util-linux-2.31.1 > > > > merge time: 27 minutes and 48 seconds. > > > >=20 > > > > Sat Mar 31 08:07:20 2018 >>> sys-apps/util-linux-2.32 > > > > merge time: 28 minutes and 44 seconds. > > > >=20 > > > > Mon Aug 27 06:21:30 2018 >>> sys-apps/util-linux-2.32.1 > > > > merge time: 32 minutes and 58 seconds. > > > >=20 > > > > Tue Nov 13 10:03:58 2018 >>> sys-apps/util-linux-2.33 > > > > merge time: 1 hour, 19 minutes and 49 seconds. > > > >=20 > > > > Fri Jan 11 09:20:21 2019 >>> sys-apps/util-linux-2.33.1 > > > > merge time: 1 hour, 23 minutes and 37 seconds. > > > >=20 > > > > Thu Feb 21 04:14:33 2019 >>> sys-apps/util-linux-2.33.1 > > > > merge time: 1 hour, 25 minutes and 15 seconds. > > > >=20 > > >=20 > > > 2.33 was changed to use python-r1 eclass instead of python- > > > single-r1 > > > eclass. And the increase of build time seems caused by an out-of- > > > source=20 > > > build for each python implementation. Some libraries are built > > > several > > > times (for native abi + for each python implementation). > >=20 > > And there is additional configure run for each python > > implementation. >=20 > Hmm, this might explain things, somewhat. I think there's possibly > some > truth to the getcwd bit discussed earlier, but that may be limited to > glibc > only. Right, util-linux doesn't conduct that test. coreutils and tar do, maybe some more. That doesn't mean running with sandbox doesn't have a slowdown effect - it most certainly does, just hopefully not so drastic as that particular case - it involves glibc own generic getcwd being slow with long paths, and sandbox calling it three times for its access checks even for mkdir call, just to error with ENAMETOOLONG, in addition to many getcwd calls the configure check itself does. So it's slow even without sandbox, but with sandbox that slowness is doubled or more. That has made me wonder if maybe by having some more ENAMETOOLONGs earlier, the test would finish earlier, instead of slowly spinning through paths that are in length between PATH_MAX and PATH_MAX*2, when it's slow.. But not sure why these m4 macros seems to be calling getcwd after each mkdir+chdirm etc just to get a boolean configure check result. Didn't look into the specific case, I only debugged the test case that just loops mkdir+chdir. Someone should maybe convert these project to meson and do that check smarter :D > util-linux-2.33.1 on my uclibc-ng chroot took about ~25mins. Have to > re-time the glibc build to see if it's something w/ the libc > implementation. >=20 > Temp workaround I guess is to cut down on the PYTHON_TARGETS before > my next > catalyst attempt. 2.7 + 3.7 should be enough... Personally I seem to get by with just USE=3D-python on util-linux (it's actually not globally enabled on my systems, it seems). Otherwise, sure, if the slowness is in configure. Mart --=-ziatUhPNLQRu1MDbowGM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQKTBAABCgB9FiEEUdZn9pOq0mlNjRvdEKbJ+k9JlgYFAlx5SVNfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDUx RDY2N0Y2OTNBQUQyNjk0RDhEMUJERDEwQTZDOUZBNEY0OTk2MDYACgkQEKbJ+k9J lgbZ+A/+MDealduTQjiasOGjgAeqj2Zn2BNCCwnkNxMfWEuuPbQC457MenmsNgCJ 41Rged+pOl9Xu956CT3jwoVoF1uBuVGDHCmtWXpgr2mB0dSBn6Z8ldXuyy6KfxyP xaqqnv+McPtDhhNn7ZBqhQPAMptpCJ/8pV/76whUeNJQXLs7Ih6SHZ9VEd9z2vqY IkQutxiJmH8shcxGlsvZ7wizYqCR8HSLrPrv0SN2RDdIS0v4urE6NpZg6QPLg+Fj Lhmhcj8KsypsEMcu/3Jeo+OudixiRBJLqi+5d6ODsjObIh2E/YP3XyKq/HQfs6Vu nBQgHRlwLN3SgwhPa/kNm6tBGFDq75XYxNT9+JWo/qV+P/s9p2vy56X7za97OK3b IFOure/gsjbMmqrybLKTJFHVf1/skmaS8ukdGH+mQQLSGY9g7lksStPxon8v0LTu DvThrsOVSelOWzaOo2NJDdZXNQdCmrjh8Cqpgl1wqndyFDHJUkN7U+htKwnCoN36 R34Yl2EyEj6RBIg3wOhCPzFmqtd0Ps1sQLkZCshdVGUeJ5DfpOdVhYyXdCnsNVOL n0h37FGlhIo3qgALrECUi7W/0algyvzLxYr+x/crhwfuBlG2ttz5wTqVsp20SsgH P1ZT5vRgokceDQoBaPrQsHjq+1AFa6GYMvIKlNuA0zYCGhKncPY= =+EVf -----END PGP SIGNATURE----- --=-ziatUhPNLQRu1MDbowGM--