On Sun, Jan 12, 2025 at 2:36 PM Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote: > > On Sun, Jan 12, 2025 at 05:21:18PM +0100, Vitaly Zaitsev via devel wrote: > > On 12/01/2025 13:02, Christoph Erhardt wrote: > > > 1. Not all packages but only those whose maintainers explicitly opt in. > > > > Yes, at the first stage. But over time the number of packages can increase > > significantly. > > I think any massive use of this scheme is unlikely. Note that we'd > want to this only for packages where the optimized code yields > noticeable benefits. There just aren't that many packages which do > significant number crunching _and_ don't already use some kind of > runtime cpu detection. > > > > 2. The duplication will affect only the executable ELFs - i.e. the > > > contents of `/usr/bin` - shipped by these packages. There will be no > > > duplication of shared libraries, data files or anything else. > > > > Shared libraries used by affected packages should also be rebuilt with these > > optimizations. For example, Firefox has most of its logic in *.so files. > > > > > One effect this *will* have is a slightly increased latency for > > > launching an affected program. > > > > How much? > > Benchmarks indicate 100–1000 μs. My concern is that this defeats most methods of observability. It's essentially the same as the double-fork problem we used to have with system services. The stub will fork out and exec a new binary, which means you lose track of the binary and can't reliably trace it. To be honest, this only makes sense for ad-hoc stuff (like stuff installed in the user's ~/bin or ~/.local/bin directories) rather than something installed system-wide. For stuff installed into /usr, we should just allow packages to be optionally built with the higher microarchitecture level in addition to the base one and allow DNF to sort and prefer packages accordingly. -- 真実はいつも一つ！/ Always, there's only one truth! -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
