[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fedora-devel-list
Subject:    Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update
From:       "Tobias Guggenmos" <tguggenmos () fedoraproject ! org>
Date:       2019-08-08 17:17:39
Message-ID: 20190808171739.26017.20879 () mailman01 ! phx2 ! fedoraproject ! org
[Download RAW message or body]

> * Stephen Gallagher:
> 
> 
> Can we make this happen at the RPM level?  So that third-party RPMs
> install just fine even though the operating system is something else
> (not x86_64 anymore)?  I do not see many explicit dependencies on
> anything "x86_64" in Fedora 30, so perhaps this is doable, assuming that
> packages of the other architecture would continue to provide …(…)(64bit)
> for soname dependencies.
> 
> Could we rebuild x86_64 Fedora with a different dist tag and different
> compiler flags, and release that as a new spin?  And retain the x86_64
> for that architecture?
> 
> Regarding doing something like the old i686 packages when we had an i586
> baseline (or the ppc64p7 work that was perhaps never upstreamed to
> Fedora), I'm a bit worried about increasing the complexity of composes.
> We already see upgrade issues doe to i686 packages come and go, and that
> could potentially multiply them.  The advantage is that packaging
> changes themselves will be relatively minor, once we have agreemeent
> which packages should do this.
> 
> ELF multilib DSOs inside RPMs result in code deduplication, affecting
> container image size.  Packaging changes are *not* minor for this
> approach.  It can be tricky to ensure full testing coverage if both DSOs
> are installed.  Currently, there is no dynamic loader support for
> selecting an AVX2 baseline.  Fixing this requires complete agreement
> among all involved parties what the actual CPU requirements are
> (currently, not even glibc and GCC agree what "haswell" means, the
> closest we have to an AVX2 baseline).  But similar fixes are required
> for any baseline update.
> 
> Thanks,
> Florian
> * Stephen Gallagher:
> 
> 
> Can we make this happen at the RPM level?  So that third-party RPMs
> install just fine even though the operating system is something else
> (not x86_64 anymore)?  I do not see many explicit dependencies on
> anything "x86_64" in Fedora 30, so perhaps this is doable, assuming that
> packages of the other architecture would continue to provide …(…)(64bit)
> for soname dependencies.
> 
> Could we rebuild x86_64 Fedora with a different dist tag and different
> compiler flags, and release that as a new spin?  And retain the x86_64
> for that architecture?
> 
> Regarding doing something like the old i686 packages when we had an i586
> baseline (or the ppc64p7 work that was perhaps never upstreamed to
> Fedora), I'm a bit worried about increasing the complexity of composes.
> We already see upgrade issues doe to i686 packages come and go, and that
> could potentially multiply them.  The advantage is that packaging
> changes themselves will be relatively minor, once we have agreemeent
> which packages should do this.
> 
> ELF multilib DSOs inside RPMs result in code deduplication, affecting
> container image size.  Packaging changes are *not* minor for this
> approach.  It can be tricky to ensure full testing coverage if both DSOs
> are installed.  Currently, there is no dynamic loader support for
> selecting an AVX2 baseline.  Fixing this requires complete agreement
> among all involved parties what the actual CPU requirements are
> (currently, not even glibc and GCC agree what "haswell" means, the
> closest we have to an AVX2 baseline).  But similar fixes are required
> for any baseline update.
> 
> Thanks,
> Florian


Something like this sounds like a good idea to me. 

Would it be possible to work this out into a standardized way to provide support for \
multiple ISA levels, e.g. avx, avx2, avx512 or whatever might come up in the future? \
That way fedora could stay up to date with recent cpu developments without regularly \
having discussions like this one.

Instead of providing multiple x86_64 spins, where each user has to figure out on \
their own which one to use, it might be better to only deliver installers with the \
baseline and let them figure out the right optimized packages at install time. \
_______________________________________________ devel mailing list -- \
devel@lists.fedoraproject.org To unsubscribe send an email to \
devel-leave@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


[prev in list] [next in list] [prev in thread] [next in thread]