On Mon, Feb 27, 2023 at 4:46 PM Neal Gompa <ngompa13 at gmail.com> 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. > > I also would not suggest calling this the x86 SIG, since that is > misleading. Consider expanding to compiler flag analysis and tuning I don't think it's misleading at all. The proposal is pretty clear that they're looking at x86_64 and that's it. It might not be what you would recommend, but I don't think they are misleading anyone with the proposal as written. > 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. I disagree. What you suggest is certainly a direction that could happen, but it's big, grand, and unwieldy. By retaining a scope on a specific architecture, the SIG can focus and make concrete, actionable suggestions and improvements. I certainly appreciate larger and more comprehensive efforts, but I think we collectively bite off more than we can chew sometimes. I find a SIG with a specific goal refreshing. > 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? I think there's certainly an aspect of this that ELN plays a part in, but I don't see it as a good basis for the comparison aspects without doing more throwaway work. josh > 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