From Fedora Project Wiki

Additional buildroot to test x86-64 micro-architecture update


Create a dedicated buildroot to test packages built with x86-64 micro-architecture update.


Current status

  • Targeted release: Fedora 32
  • Last updated: 2020-02-24
  • Tracker bug: #1806732
  • Release notes tracker:

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 was rejected as in its current form it is not compatible with the large amount of machines available. But we would like to unblock the development and testing of this feature on the side, so that we might find a compromising or alternative implementation for it.

Any solution which we find as a result of this work won't be automatically added to Fedora, but will go through the regular Change process with its own round of discussions and approvals.

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.


  • 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
  • Other developers:
    • None. The goal is to build exactly the same sources in the different buildroot environment. Thus maintainers supposed to work on Fedora Rawhide packages as usual. With maybe additional source of bugreports coming from the build failures.

  • Release engineering: #9154
    • New buildroot needs to be configured in koji
    • New compose configuration
  • Policies and guidelines: #941
    • There will be a new disttag for the alternative buildroot and a new conditional in the rpm spec for it.
  • Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

N/A (not a System Wide Change)

How To Test

(Will be updated with more details later)

For each new package submitted to Fedora Rawhide there will be a CI pipeline which builds the same sources in the additional buildroot. Build result will be posted to ResultsDB and will be visible in Bodhi on the update page.

There also is going to be partial compose with all packages built in the alternative buildroot.

To test these packages one can add the repository from the compose and run a dystro-sync.

User Experience

The alternative buildroot is going to be used for development and testing. There will be no impact on users.


N/A (not a System Wide Change)

Contingency Plan

The only impact the feature has on the current Fedora development process is: there will be additional test result which shows up in Fedora Rawhide gating. Thus there is no risk for Fedora release process.

If feature is not completed by Fedora 32 release, it is going to be shifted to Fedora 33 cycle or cancelled.

  • Contingency mechanism: N/A (not a System Wide Change)
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? N/A (not a System Wide Change)


There will be a landing page on wiki with details on the purpose and usage of this buildroot.

Release Notes

Preparation work has started for updating Fedora baseline to new CPUs. While it has no effect on the current release, there is a test environment which can be used by anyone interested in this work.