On Thu, Jan 09, 2020 at 03:59:41PM -0500, Neal Gompa wrote: > On Thu, Jan 9, 2020 at 12:17 PM Ben Cotton <bcotton@xxxxxxxxxx> wrote: > > > > https://fedoraproject.org/wiki/Changes/Additional_buildroot_to_test_x86-64_micro-architecture_update > > > > == Summary == > > > > Create a dedicated buildroot to test packages built with x86-64 > > micro-architecture update. > > > > == Owner == > > > > * Name: [[User:bookwar| Aleksandra Fedorova]] > > * Email: [mailto:alpha@xxxxxxxxxxxx alpha@xxxxxxxxxxxx] > > * Name: [[User:fweimer| Florian Weimer]] > > * Email: [mailto:fweimer@xxxxxxxxxx fweimer@xxxxxxxxxx] > > > > == Detailed Description == > > > > Fedora currently uses the original K8 micro-architecture (without > > 3DNow! and other AMD-specific parts) as the baseline for its x86_64 > > architecture. This baseline dates back to 2003 and has not been > > updated since. As a result, performance of Fedora is not as good as it > > could be on current CPUs. > > > > Changing the main Fedora baseline to new CPUs in place > > [[Changes/x86-64 micro-architecture update|was rejected]] as the user > > base for older machines is still large. But we’d like to unblock the > > development and testing of this feature. > > > > == Benefit to Fedora == > > > > * Allow development and verification of the CPU baseline update in > > Fedora without disrupting users of Fedora on older machines. > > * Collect real life data on performance improvements, which can help > > making decision on the baseline update. > > * As soon as feature is accepted by the community, there will be a > > smooth process to update baseline in the main Fedora, as all packages > > will be already verified and tested to work against it. > > * Until the switch of the main x86_64 architecture, interested parties > > can install systems from the updated buildroot for performance > > experiments. > > > > == Scope == > > > > * Proposal owners: > > ** define new disttag for the buildroot > > ** provide updated gcc package which implements the new compiler > > flags. It is expected that the new baseline will be implemented in a > > new GCC -march= option for convenience. > > ** provide update to rpm-config package which changes default compiler > > options for the disttag > > ** setup automation so that for each build submitted to Fedora Rawhide > > there is a build submitted to the additional buildroot. Result of the > > build task will be posted to Fedora Messaging and consumed by > > ResultsDB, so that it appears in Bodhi > > ** setup automation to run periodic partial composes (via ODCS) > > without installation media to generate repositories with these > > packages > > ** update packaging documentation to mention new disttag and how it can be used > > ** create landing page to describe the purpose and usages of the > > buildroot in Fedora Wiki > > > > Three things I'm concerned about: > > 1. Our builder resources are squeezed enough as it is. In doing this, > are we going to get more machines so that we can have more builders? > Between modules and this, I worry our resources will get squeezed far > too tightly for my comfort. > 2. This feature does not describe what the new microarchitecture > baseline will be. I *could* assume it's the crazy new > microarchitecture that was proposed in the rejected Change, but I > don't want to make that assumption. Please specify. > 3. Why is this in the main Koji and require a new disttag? Why not > just do a shadow Koji and build in an alternate path? Every other > architecture bringup has required this process, I don't see why this > one wouldn't too. That would also deal with my concern for (1), since > a shadow Koji would be required to have its own builder resources > separate from the main one. > > Note that there's basically no reason to do weird things to > redhat-rpm-config, especially if you go the shadow Koji route, since > you can specify macros on a per tag basis. This includes overriding > the target platform and setting extra flags for optimizations. Those are all good points. To add more: 4. This certainly needs to be a "system wide change" with the related additional info required for such changes. We certainly need releng to sign off on this. 5. "Additional bugs", i.e. most likely build failures, but probably also runtime failures are mentioned. Who will be on the hook to fix those? Does failure to build block anything? > As a side note, I'm surprised people are so weirdly focused on > Intel-specific optimizations, when it seems like AMD CPUs might > benefit from some love directly, especially with new Ryzen chips > becoming more popular. Zbyszek _______________________________________________ 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
