On Mon, Feb 27, 2023, at 15:45, Neal Gompa wrote: > 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. We can provide separate disttags to this group. I think that given the mission they'll be incentivized to pay close attention to the NVRs between the distro and SIG content. > > 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! > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > https://lists.centos.org/mailman/listinfo/centos-devel --Brian