On Mon, Feb 27, 2023 at 12:23 PM Florian Weimer <fweimer at 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!