On Sun, Jan 12, 2025 at 2:36 PM Zbigniew Jędrzejewski-Szmek
<zbys...@in.waw.pl> 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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Reply via email to