4:25 a.m.
On Tue, Jan 10, 2023 at 5:11 AM David Abdurachmanov
<david.abdurachmanov(a)gmail.com> wrote:
On Mon, Jan 9, 2023 at 3:22 PM Josh Boyer <jwboyer(a)fedoraproject.org> wrote:
>
> On Mon, Jan 9, 2023 at 9:15 AM Neal Gompa <ngompa13(a)gmail.com> wrote:
> >
> > On Mon, Jan 9, 2023 at 8:47 AM Josh Boyer <jwboyer(a)fedoraproject.org>
wrote:
> > >
> > > On Sun, Jan 8, 2023 at 2:42 AM David Abdurachmanov
> > > <david.abdurachmanov(a)gmail.com> wrote:
> > > >
> > > > On Sun, Jan 8, 2023 at 2:28 AM Jeff Law <jlaw(a)ventanamicro.com>
wrote:
> > > > >
> > > > >
> > > > >
> > > > > On 1/6/23 23:41, David Abdurachmanov wrote:
> > > > > >
> > > > > > Summary from multi-year discussions/feedback on this:
> > > > > > - We don't have proper hardware to put into the data
center that holds
> > > > > > servers used by Fedora infrastructure.
> > > > > Right. dev boards are not the solution here. It's got to
be something
> > > > > that can be racked and with enough performance to matter.
> > > > >
> > > > > > - Not enough single and multi thread performance to avoid
large impact
> > > > > > to Fedora development.
> > > > > Agreed. Returning to a situation like we had with armv7
isn't
> > > > > acceptable IMHO.
> > > > >
> > > > > >
> > > > > > Other than that Fedora/RISCV 37 is the first Fedora version
to be
> > > > > > built fully natively using 20+ SiFive HiFive Unmatched
boards. On a
> > > > > > good day we can keep up (if the builds aren't too
large, e.g. GCC). We
> > > > > > don't really run Bodhi thus once package is built
it's immediately
> > > > > > available. We run a very minimal setup right now (ideas to
expand
> > > > > > that).
> > > > > It's fantastic we've got that far. But clearly it's
not viable long term.
> > > >
> > > > Agreed. We have been cooking Fedora/RISCV since 2016, but we really
> > > > cannot move forward until the proper hardware (and things around it)
> > > > becomes available.
> > > >
> > > > >
> > > > >
> > > > > > Another news is that Fedora/RISCV Koji server (
> > > > > > http://fedora.riscv.rocks/koji/ ) just moved into Fedora
infra owned
> > > > > > server. We are about to start work on Fedora 38/Rawhide.
> > > > > Excellent. I'll have to update my chroots and containers as
the F38
> > > > > bits start appearing.
> > > >
> > > > I am still tweaking the server configuration, but I should be ready
> > > > for mass building soonish.
> > > > I might want to wait for GCC 13 to land in Rawhide, which should
> > > > happen soon (I think).
> > > >
> > > > >
> > > > > >
> > > > > > 2023 is potentially a transition year. Ventana Veyron V1
Development
> > > > > > Platform looks good (I assume it has BMC). SOPHGO SG2042
should also
> > > > > > show up with 64-core @ 2.0GHz (T-HEAD C910) in early 2023
(?) I am not
> > > > > > yet convinced about their upstream support efforts (TBD).
> > > > > Yes Veyron-v1 will have a BMC and will be rackable. I have no
> > > > > significant insight into the T-HEAD efforts other than they do
work a
> > > > > fair amount with VRULL on compiler and related technology.
> > > >
> > > > I noticed that VRULL has been involved with T-HEAD on GCC and
> > > > potentially kernel side for a few months now. This makes them much
> > > > more optimistic about their SoC/HW support in general.
> > > >
> > > > >
> > > > >
> > > > > >
> > > > > > If there is away to acquire Veyron V1 Development Platform
I would be
> > > > > > interested to talk, and figure out what that would take.
Such hardware
> > > > > > would be a game charger, and I do trust Ventana regarding
upstream
> > > > > > support :)
> > > > > I'll be pushing to make systems available to Fedora and the
GCC farm,
> > > > > but in general Ventana is more aligned towards Ubuntu. My goal
is to
> > > > > have Fedora and Ubuntu on equal footing as quickly as possible.
> > > >
> > > > We have been trying to get stuff into GCC Compiler Farm for years
now.
> > > > There are a couple of boards IIRC. There are additional requirements
> > > > on the software side (well, distributions) that we couldn't
provide
> > > > for quite some time.
> > > >
> > > > >
> > > > > I do know rackable systems will be limited -- there's one
particular
> > > > > component needed on the rackable systems that is in very short
supply.
> > > > > We've got multiple orders in, but quantities are limited and
lead times
> > > > > are absolutely insane.
> > > >
> > > > FYI, I think, the new aarch64 builders are 8 core, 35G RAM and 8G
> > > > swap. The older machines had 8G/core setup. There seems to be 8 (?)
> > > > servers with 80 cores, but so far only 40-50 builders are enabled
(no
> > > > overcommitting on CPU as that's not a great idea [based on my
own
> > > > experience]).
> > > >
> > > > I expect Veyron V1 to deliver a decent single and multi thread
> > > > performance, but we will need a lot of them. Probably 20-25 systems
if
> > > > we assume a similar configuration as aarch64 builders (8-core,
32-64G
> > > > of RAM, 100-200G for storage). RAM and storage are cheap, but
systems
> > > > will continue to be a problem. If we could somehow get to this level
> > > > we could stop investing into SBCs as they are stop-gap solutions for
> > > > builders.
> > > >
> > > > Based on some guesses there isn't a lot of time either. I would
love
> > > > to bootstrap CentOS Stream 10. It would be nice to have Fedora +
> > > > riscv64 in a good shape before that happens, but probably
unrealistic.
> > >
> > > It is very unlikely that CentOS Stream 10 will include RISC-V as a
> > > fully included architecture. Perhaps via a CentOS Stream SIG.
> > >
> >
> > I believe that was the implication in the first place, hence
> > mentioning CentOS Stream rather than RHEL.
>
> Better to be clear about direction up-front, so thanks for clarifying.
> "CentOS Stream" is used as both an umbrella term and a specific OS and
> it causes confusion sometimes.
Yes, that would be CentOS Stream SIG. There is interest in this.
>
> > The Alternative Architectures SIG in CentOS would be where this would
> > happen. But the work needs to be done in Fedora first.
>
> Alternative Arches would totally make sense to me. And agreed Fedora
> needs to land first.
Agreed. Doing some prediction based on the history, we have 2-3 Fedora
releases before CentOS Stream 10 might happen.
Without EPEL CentOS Stream (package wise) is not large. Of course the
majority (if not all) users consider EPEL an important part of the
experience.
There is precedent for the AltArch SIG to rebuild EPEL for an
alternative architecture. I think the way it would be done today would
necessarily need to be different from how it was done in the times we
build 32-bit x86 and ARM support with CentOS 7, but it's absolutely doable.
--
真実はいつも一つ！/ Always, there's only one truth!