Hi, Neal, On Thu, Jan 9, 2020 at 10:01 PM Neal Gompa <ngompa13@xxxxxxxxx> 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. In this change we are looking for x86_64 builders only, and we will run one additional build for every regular (non-scratch) build in Fedora rawhide. I think the load it brings should be bearable, but maybe Releng can provide the estimate. > 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. The rejected change https://fedoraproject.org/wiki/Changes/x86-64_micro-architecture_update is explicitly referenced from the current one. So yes, it is the architecture update we are looking for. And I would suggest to avoid calling things weird and crazy just because you are not interested in them. > 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. 1) There is no new architecture, it is the same x86_64 architecture as usual, with only the default compiler flags changed. Thus, unlike with other architectures, there is no need for new hardware and new koji builders. We can use exactly the same x86_64 koji-builders as usual, which saves resources of Releng and other teams. 2) Separation of resources is not really a solution for the lack of capacity. It makes it worse, because separate resources can not be used by other tasks. It is usually more effective to have a shared pool of compute(in our case - build) power, and use it for various tasks, prioritizing them. In the proposed setup there will be a CI machinery, which will trigger new builds for every new Bodhi update in Fedora Rawhide. We will have a possibility to stop and reschedule the tasks, if there will be a lack of resources required for mass rebuilds or some other high priority tasks. > 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 -- Aleksandra Fedorova bookwar _______________________________________________ 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
