On Mon, Feb 27, 2023 at 12:23 PM Florian Weimer fweimer@redhat.com wrote:
# Goals
The purpose of this SIG is to quantify the potential benefits of applying existing compiler technology to distribution packages, targeting more recent CPUs, and evaluating different options for how these optimizations can be maintained in a scalable way, and delivered to end users.
Today, there is a significant delay between the release of new x86-64 ISAs and the adoption across the entire CentOS distribution. For example, CentOS 9 Stream released with the x86-64-v2 ISA baseline, nine to thirteen years after such CPUs became commercially available. The concern is that this discrepancy leaves more recent CPU features unused, and end users do not see the best possible performance for the CPUs they use.
Parts of the distribution are built with run-time selected optimizations, but this only applies to specialized functional areas, such as string manipulation, certain mathematical operations, and cryptography, but not (for example) to language interpreters that are part of CentOS.
# Status
Proposed: RFC and looking for a sponsoring Governing Board member
# What’s in scope
Explore the immediate runtime performance impact of package-specific ISA-related work on key workloads e.g. language interpreters.
Evaluate the performance benefit at run-time of building CentOS with auto-vectorization and the very-cheap cost model and different x86-64 micro-architecture levels.
Explore ways how these performance-enhancing builds can be maintained at the distribution level and made available to end users for installation.
Assess the image/container size impact of those additional optimized builds (this may not be applicable to some delivery mechanisms).
Explore ways to alert users that they do not get optimal performance because of misconfigured hypervisors.
It is possible, but not likely, that work across the entire distribution may be needed to enable shadow stacks. (Userspace enablement happened as part of CentOS 8, but the kernel parts are not upstream and have changed significantly, so there is some uncertainty.) If large-scale work affecting many packages is needed, the SIG would be a natural place to prototype changes before integration into the distribution.
# What's not in scope
Enablement for future x86 CPUs and chipsets, assemblers, linkers, and compiler support for new ISAs including regular performance work on individual packages (e.g., identified upstream backports). Hardware enablement must follow existing processes.
Any 32-bit work (such as 64-bit time_t, or a 32-bit kernel) is explicitly excluded.
The focus will be on userspace changes.
Rebuilds for potential observability improvements are out of scope (although shadow stacks are expected to help in this a
Adding additional hosts to the CentOS infrastructure in support of this SIG needs to be negotiated with the CentOS infrastructure team. The CPU microarchitecture level of the existing infrastructure is already sufficient.
# Roadmap
March 2023: Start the SIG and coordinate with partners April 2023: Adopt existing CentOS builder resources to deliver the required builds. May 2023: Initial performance analysis results.
Rest TBD based on results of exploration.
Resources
They SIG could benefit from spare x86-64 Koji builder capacity.
Note that SIGs do not have access to distribution Koji. This would be hugely problematic to do in CBS given all the potential collisions in NVRs that it could create. I would suggest if this SIG is greenlit that a dedicated Koji instance would be spun up for this.
I also would not suggest calling this the x86 SIG, since that is misleading. Consider expanding to compiler flag analysis and tuning across all CentOS architectures rather than just narrowly looking at x86_64 micro-architecture levels. That ensures this SIG has some reasonable longevity rather than being a weird short-term experiment thing. It is worth exploring improvements for all architectures, since research on that front doesn't happen enough as it is. You could still start with x86, but giving opportunities to grow beyond that would be better for the community overall if this is done.
Another aspect, I'm not sure what value this provides because existing CentOS/RHEL releases can't change, so wouldn't this make more sense to do as alternative Koji roots for Fedora ELN, which is closer to CentOS Stream 10 than anything in the CentOS Project has?
Additionally, what is your plan for community engagement? What kind of contribution model do you plan to have? Finally, do you have a group of folks in mind you're interested in reaching out to participate in CentOS for this?
-- 真実はいつも一つ！/ Always, there's only one truth!