Date: Tue, 5 Oct 2021 23:57:27 +0200 From: Piotr Kubaj <pkubaj@anongoth.pl> To: Matthias Andree <mandree@freebsd.org> Cc: ports-committers@freebsd.org, dev-commits-ports-all@freebsd.org, dev-commits-ports-main@freebsd.org, Mathieu Arnold <mat@freebsd.org> Subject: Re: git: fb5f03a87cf4 - main - Mk/bsd.lto.mk: add global LTO support for ports Message-ID: <YVzKR0wwAkfOFurC@KGPE-D16> In-Reply-To: <607e0aa1-3888-8a61-f80f-0aad1d53ea23@FreeBSD.org> References: <202109301834.18UIYKrL013410@gitrepo.freebsd.org> <20211004133056.z7e2iyrhlwprvvvp@aching.in.mat.cc> <YVx84wGVlSr2nmBX@KGPE-D16> <20211005163152.gv2vwvg4nuqwga7q@aching.in.mat.cc> <YVyCEPlZJvdce4Ak@KGPE-D16> <44365771-0a1d-7bcb-2cb6-85f592624a3b@FreeBSD.org> <YVy4gsubg0nsG1Nq@KGPE-D16> <607e0aa1-3888-8a61-f80f-0aad1d53ea23@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--HW1j+w538OPDvsip Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 21-10-05 22:48:14, Matthias Andree wrote: >=20 > Am 05.10.21 um 22:41 schrieb Piotr Kubaj: > > On 21-10-05 22:04:32, Matthias Andree wrote: > >> > >> Am 05.10.21 um 18:49 schrieb Piotr Kubaj: > >>> On 21-10-05 18:31:52, Mathieu Arnold wrote: > >>>> On Tue, Oct 05, 2021 at 06:27:15PM +0200, Piotr Kubaj wrote: > >>>>> On 21-10-04 15:30:56, Mathieu Arnold wrote: > >>>>>> On Thu, Sep 30, 2021 at 06:34:20PM +0000, Piotr Kubaj wrote: > >>>>>>> The branch main has been updated by pkubaj: > >>>>>>> > >>>>>>> URL: https://cgit.FreeBSD.org/ports/commit/?id=3Dfb5f03a87cf43275= 1fae1f0ae7f29c9d4fc65917 > >>>>>>> > >>>>>>> commit fb5f03a87cf432751fae1f0ae7f29c9d4fc65917 > >>>>>>> Author: Piotr Kubaj <pkubaj@FreeBSD.org> > >>>>>>> AuthorDate: 2021-09-30 18:27:50 +0000 > >>>>>>> Commit: Piotr Kubaj <pkubaj@FreeBSD.org> > >>>>>>> CommitDate: 2021-09-30 18:27:50 +0000 > >>>>>>> > >>>>>>> Mk/bsd.lto.mk: add global LTO support for ports > >>>>>>> =20 > >>>>>>> It's well known that LTO provides both performance and size b= enefits for > >>>>>>> binaries. > >>>>>>> =20 > >>>>>>> Add preliminary, opt-in support for global LTO enforcement to= ports. Ports that > >>>>>>> provide LTO option on their own and the ones that don't work = with LTO will need > >>>>>>> to set LTO_UNSAFE in the future. > >>>>>>> =20 > >>>>>>> PR: 258536 > >>>>>> > >>>>>> Not to be picky about approval and all, but this was added to the > >>>>>> framework, and the framework is maintained by portmgr. When you w= ant to > >>>>>> add something to it, you must consult with portmgr before anything= gets > >>>>>> committed. > >>>>>> > >>>>>> In that case, we would have told you not to do it this way, but to= make > >>>>>> this a Mk/Uses/lto.mk. > >>>>>> > >>>>>> So please, turn this into a USES=3Dlto. > >>>>> > >>>>> I did consult, but no one replied. > >>>> > >>>> There is absolutely no maintainer timeout for the framework, you can= not > >>>> just add code there without explicit approval. > >>> > >>> And this is a port of a bigger issue, where portmgr ignores emails un= til numerously asked for (if one is lucky). > >>> As one of users wrote in https://bugs.freebsd.org/bugzilla/show_bug.c= gi?id=3D251117, for which portmgr is assigned, "portmgr@ more and more feel= s to me like a black hole, or /dev/null: Anything sent there seems to disap= pear without effect." > >>> > >>> Since it was a change that doesn't change anything out-of-the-box, I = decided to commit it. > >>> > >>>> > >>>>> IMO adding it to USES is not a good idea, since USES are supposed t= o be used per port and my idea was to force LTO for all ports, same way tha= t SSP already does. > >>>> > >>>> All I see in the patch is a USE_LTO knob, and a LTO_UNSAFE one, with= out > >>>> any documentation of what it is for, what it does, what it might do, > >>>> what it is about, or anything else. > >>> Neither has SSP, I don't see any documentation for it (including comm= iter handbook which has just one line regarding USES=3Dkmod at https://docs= =2Efreebsd.org/en/books/porters-handbook/book/#uses-kmod). > >> > >> Piotr, > >> > >> While I sympathize with your findings about portmgr@ 'responsiveness' > >> having had my shares of ignores and brushes, I would tend to agree that > >> we should not add undocumented knobs anywhere, so: > >> > >> 1. please add documentation including motivation > > OK, just take note that there are several issues with it right now, so = it's definitely not ready for use. E.g. libffi, perl and pkgconf don't buil= d. > >=20 > > Other than that, what is the best place for documentation? Do you mean = porter's handbook? >=20 > Assuming we're going the bsd.lto.mk path, the comment banner at the top > of this new file would be the most obvious place. Purpose, how-to, > reference. Anything else might be a proposal in whatever format. Talk > to the doc committers or doceng@ maybe? >=20 > > That's what we have package builders for. AFAIK they run Poudriere with= out ALLOW_MAKE_JOBS, so mostly single-threaded. > > If LTO is ever enabled for everyone, we should still keep a knob to dis= able it globally. >=20 > Yes, but my personal poudriere builders are on disk-space constrained > VMs so get maximum parallelity within one job, and run few jobs in > parallel. It's not ideal, but I can't build LLVM, Rust, and JDK or > texmf in parallel with its truckloads-of-GBytes build directories. >=20 > Before committing intrusive changes, we normally do -exp runs. > Personally, for OpenEXR which is one of the more "central" ports I have, > I dare building all ports depending on it locally before committing, if > I couldn't do that I'd have to go for an -exp run. I myself have enough RAM for using LTO even with large software. If your ha= rdware can't allow that, there were free Azure VMs that AFAIK were quite be= efy. >=20 > HTH --HW1j+w538OPDvsip Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEycyIeNkkgohzsoorelmbhSCDnJ0FAmFcykcACgkQelmbhSCD nJ0lyw/+KNQ5iNo4oxj7pPlQJT6jfwM1vFKYZao8DuauXxoNqRfxE+6WSOXCIf0o 2HHWDZmyIJLAaYEYs3HGlSptsLcINzMyqubU7ts1IFhMaMlih+Of0pdtoebeOYHf hU6ugeayMWvaERbVeeOmkgpHuGEs1nHsRQYuFmsYMcyh3096Z3RfT6Tbrw54C5sp vrdIyZMHXbTRbHauyezKtrMDt0eT2uLQGxfcxECba7F2TV8PKg6EpwR8LcJ7X9EB YJRxfgjZ9tTcotXyCR8VYtzl8H6YWI5hfoBwI9dvqzQr2x8qhLrgfhTQgzqp0K4Y eeErHGwvuOYPQKwCUeJMSkVcVldQrnMKLFyqqykni/ykz89klcQrVGNzstUBgAKS LkTk8sLcaaCzObIzA5k+Euon5nVlvJ6ThYR1YSC/yd9K490Yfw6Kw38hkui+4t3H UiEs8L0dw4N2gaB9E19KEeU4iRZ0F5XYSlbkPPtUvo3EV1ZPDtt0grS3zUx9vdJ5 ulTjmO3h00L6o4gml12rDv+GMGCh88Ni4hg50eUpbym1Tigs3yxjNP0V1DXkxBFB Bcj5hAGky982k4JU7mR8sXBu7yaajNojAWd2ZX+cw91Qm3kW+E/hH2PcDpsvQTHD M6fXnnzxh2hUN6YN1H4fo/HTSgRZGkdb/rk59VV23DrRGGaTl7k= =Q7Pg -----END PGP SIGNATURE----- --HW1j+w538OPDvsip--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YVzKR0wwAkfOFurC>