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. 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. -- 真実はいつも一つ！/ 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
