Created attachment 266810 [details] Patch for cmake-core As we hardcode thin LTO to one thread [1] it makes little sense to use it over fat which performs better. 1: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281765
Hi, I'd like to request an exp-run Best regrards, Daniel
Exp-run seems fine
Rather than doing this, maybe we should properly fix 281765 ?
I'll push this for now as there have been no objections and the referenced PR has been open for more than a year. I don't know what else to do than open a PR and "wait".
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=86e6270acf631ba6328693b5b33f4ef74ac7cbac commit 86e6270acf631ba6328693b5b33f4ef74ac7cbac Author: Daniel Engberg <diizzy@FreeBSD.org> AuthorDate: 2026-01-31 00:46:15 +0000 Commit: Daniel Engberg <diizzy@FreeBSD.org> CommitDate: 2026-01-31 01:34:56 +0000 devel/cmake-core: Use fat LTO instead of thin LTO As we hardcode thin LTO to one thread [1] without any resolve for more than a year use fat which performs better 1: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281765 PR: 292178 Approved by: timeout (no objections for 3+ weeks) Exp-run by: antoine devel/cmake-core/Makefile | 1 + .../cmake-core/files/patch-Modules_Compiler_Clang.cmake (new) | 11 +++++++++++ 2 files changed, 12 insertions(+)
(In reply to Antoine Brodin from comment #2) This change may need to be monitored, as, so far as I know, exp-runs do not test for issues like, given the various official builder-machine RAM+SWAP and cpu count configurations (some counts are estimates based on load average and percent information). For example: ) Does the change scale well to builders with 64 amd64 cpus (e.g., beefy21)? ) 96 amd64 cpus? (e.g., beefy24) ) 160 aarch64 cpus (e.g., ampere4 and ampere5 --but only 256 GiBytes of RAM each) Going along with that is the number poudriere builder process that are run in parallel and what they happen to be doing at the time. (RAM and SWAP and RAM+SWAP are not generally published or derivable from what is published by the builds.) armv7 (and non-i386 32-bit more generally) is another type of context: Also, as stands there is no official armv7 builder activity (on aarch64 with aarch32 EL0 support or on armv7 directly). So the primary source of information will be folks doing personal builds. armv7 generally limits each process to 3 GiBytes RAM+SWAP or less as I understand, including on aarch64+aarch32 hardware. For aarch64+aarch32 overall RAM+SWAP is not limited to 4 GiBytes, nor is the cpu count as limited as is common for native armv7, but on native armv7 overall RAM+SWAP is greatly limited. I expect that 32-bit powerpc is similar. None of this is an objection to trying things to find out but I'd say that it is still in an experimental stage that can only be tested live on production hardware to get the range of configurations coverage. The information available publicly for the poudriere runs on official builders is not designed to be able to track down RAM+SWAP limitations leading to OOM activity or the like. So that kind of monitoring of official builder activity will need to be done by folks with access to the relevant information. If I had known of this, I likely would have put in these kinds of notes earlier in the process.
(In reply to Daniel Engberg from comment #4) I actually did object in comment #3 and no one from kde@ explicitly approved this.
(In reply to Gleb Popov from comment #7) You phrased it as a question and I see no attempts of any further progress in the matter.
(In reply to Daniel Engberg from comment #8) Yes, that's the way I work and think. I do not block, but only express opinion and if you choose to ignore your fellow committer - whelp, so be it. As for myself, I will not go over anyone in the project even if I disagree with something.
(In reply to Gleb Popov from comment #9) Yes, but "maybe" merely suggests and no further action taken as far as I can tell. Given that I've created a PR about, referenced to it and explicitly asked for the change to be reverted https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281765#c13 with no response that course of action has already been explored. Feel free to revert if you have better means of improving the situation and please be more clear about your thoughts.
(In reply to Daniel Engberg from comment #0) Do you have some particular example build that could be used to demonstrate an example build time differences for before your commit vs. after your commit? Something publicly testable by others? At some point I might check what happens for armv7 --since there is no official armv7 build activity to do the test these days (even for armv7 via aarch64 with armv7 userspace hardware).