"Benjamin Beasley" <[email protected]> writes: > I am curious where you see this change being applied. It seems like the goal > is to help packages that currently disable LTO due to memory exhaustion on > koji builders. I wonder how many of those there are. Most packages that I > have seen disable LTO have done so due to bugs rather than due to memory > pressure. Usually these bugs turn out to be undefined behaviour in C or C++ > projects that was covered up when the optimizer could only see one > translation unit at a time. >
The motivation for this was building Highway https://github.com/google/highway where LTO lead to memory exhaustion. Having a systematic way to disable this would be helpful. > I am aware that LTO has been disabled on the RISC-V shadow koji for now due > to low-memory builder hardware, but surely that situation would be expected > to improve before promoting RISC-V to a primary architecture. A quick search > of current spec files also suggests that there are quite a few packages that > disable LTO only on 32-bit targets, i.e., on i686, but this seems acceptable > given the minor role of i686 packages in Fedora today. > > Considering 64-bit primary architectures, of the packages I have seen that do > have trouble keeping memory usage small enough to fit within koji builder > resource limits, the most common workarounds have been limiting the number of > parallel process or, where a single process uses too much memory, reducing > the debuginfo level. I’m having a hard time thinking of examples where simply > disabling LTO was enough to make the difference. It may be that I just don’t > know about these cases, and that there are quite a few such packages. It > would be nice to have more information on this. > I have not done an exahustive search. > On the other hand, if this change is less about packages that currently can’t > use LTO and more about trying to save build time for packages that already > successfully build with fat LTO objects, then how much builder time can be > saved? And what, if any, effect on the performance of the compiled programs > can be expected? If this is a compile-time/runtime performance tradeoff, it’s > hard to make an informed decision without knowing what is being traded for > what. For many programs, this information is discarded. Having an option that packagers could use to disable this consistently would also allow tracking to see if it is something that should be a default, or at least to have automated checks when not to disbale it. -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
