Write a "community initiative" for RISC-V as a primary arch #8
kashyapc
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
What?
Write up a formal "community initiative" to make RISC-V a primary architecture on Fedora. This is a long-term project with many variables in the air. Writing this initiative document will help us flesh out the details.
Quoting from here: https://docs.fedoraproject.org/en-US/project/initiatives/
The Process
Based on the section "Proposing a Community Initiative" from here: https://docs.fedoraproject.org/en-US/project/initiatives/, it seems to be a two-step process:
#counciltag.Note:
Without a "formal" initiative, a lot of essential work has already happened, or is in-progress: Koji server running on Fedora infrastructure, FAS integration, RISC-V
chroot(emulated) in COPR, etc.The "requirements" in the community initiatives document are not set in stone. The doc was written based on info the authors had at that moment in time. We will work with the Council to adapt it to the RISC-V SIG needs
Keep this process lean and efficient. The Fedora RISC-V community is small and engineering time is limited. We don't want to be mired in endless process.
Write a formal "community initiative" for RISC-V as a primary arch on Fedorato Write a formal "community initiative" for RISC-V as a primary archContext on primary vs. alternative archictures on Fedora
Fedora defines two tiers of architectures: primary, and alternative. The primary architectures serve majority of the users, currently, x86_64 and aarch64; build failures here are considered “fatal”—i.e. you can’t merge a change into a package. While alternative architectures, such as RISC-V, are maintained by “motivated Architecture Maintainer Teams”, i.e. the Fedora RISC-V SIG. Here the build failures are currently "non-fatal", meaning, they can’t block deliverables for the primary architectures.
Rough requirements:
This is an incomplete list, will add as we go:
Siddhesh, the GCC tech lead, suggested to add a "tentative build time cap" for packages as a potential requirement. The Konflux folks might have metrics on build times for various packages that may be useful data for baselines.
For GCC, he notes, RISC-V (eventually) matching the "under 30 hours" would be more or less necessary, as GCC does snapshot builds ~3 weeks.
He phrases the requirement this way:
"We currently have a 30 hour timeout for snapshot builds in copr, which is more than sufficient to build on all present architectures. That should be a reasonable goal for RISC-V builds since taking significantly longer than that would mean that we find toolchain issues much more slowly compared to other architectures."
Large scale analysis on build times would be possible, but not exact precision science. You can pull board information: board + storage from
hw_info.log, but with other things also have impact like LTO vs no-LTO-by-default, and in general buildroot is constantly changing which alone can have a big impact.In general 30 hours are too much. I must fit comfortably within <24 hours probably for GCC. The last GCC 16 for Fedora 44 took ~4:20 on x86_64 and ~5:45 on aarch64. The only arch that drags it close to 30 hours is s390x with a very slim margin.
TL;DR If you remove niche IBM arches (sorry!) you are looking at <6 hours mark to hit. That's for GCC alone.
From my current understanding we should continue to see rapid single thread performance improvements (e.g. K5, X200 is currently project to 100% and above K3 X100 cores; Reality might be different once silicon arrives).
We also loosing some performance because we have disable
/tmpontmpfs, and use Btrfs in general. Apparently it's quite an impact since on some packages (e.g. BLAS) where we need to unpack and repack a lot of object files into static libraries (those are 300+ MB IIRC).Thus performance will go up, but we also need more memory, which is ridiculously expensive today. We are swapping and thus increasing build times.
There is this
mockplugin, but it doesn't include swap statistics: https://github.com/rpm-software-management/mock/pull/1748Write a formal "community initiative" for RISC-V as a primary archto Write a "community initiative" for RISC-V as a primary archNote to self: Getting into primary Koji is a prerequisite for Primary Arch, details here:
Path for 'riscv64' inclusion in primary Koji