dgilmore changed the topic of #fedora-riscv to: Fedora on RISC-V https://fedoraproject.org/wiki/Architectures/RISC-V || Logs: https://libera.irclog.whitequark.org/fedora-riscv || Alt Arch discussions are welcome in #fedora-alt-arches
esv has joined #fedora-riscv
zsun has joined #fedora-riscv
zsun has quit [Quit: Leaving.]
davidlt__ has joined #fedora-riscv
<mbohun[m]> <neil> "davidlt: no more unmatched in..." <- Didn't they just/recently announced a new, faster board?
<davidlt[m]> mbohun: they did, HiFive Pro P550 (aka Horse Creek)
<davidlt[m]> mbohun: summer 2023 (which means up to 8 months of waiting)
<mbohun[m]> well, he could get "VisionFive v2" to ease the cravings of 8-months-long-wait :-) ?
<davidlt[m]> Good: VisionFive V2 compiles faster than Unmatched. Bad: VisionFive V2 doesn't have upstream support + has less RAM.
<davidlt[m]> So you want to mix both :)
<davidlt[m]> Some things cannot build on VF2 because of too low RAM. Unmatched is also barely working, still considered low-mem builder.
<davidlt[m]> TH1520 products launch soon too, those are faster than JH7110 (based on vendor data), and provide 4GB/core, which is again survivable.
<mbohun[m]> davidlt[m]: ...and that can't be mitigated with adding more swap? like a swapfile on the nvme ?
<davidlt[m]> That blows compile time and there timeouts you might hit.
<davidlt[m]> Not to mention those NVMe runs on Gen 2 1 lane or something.
<davidlt[m]> Which is significantly better than microSD, eMMC, etc. bandwidth and IOPS wise, but nothing impressive.
<davidlt[m]> 4G/core is kinda fine, especially if your builder has more cores.
<davidlt[m]> You most likely gonna have a few large linker execution (with LTO) that will require quite some memory.
<davidlt[m]> So 4G/core setup with 4 cores, 8 cores, 16-cores, etc. are still a different thing.
<davidlt[m]> Our build times are long thus spending money on RAM (if we could) is an easy investment.
<davidlt[m]> Since we have 16GB RAM Unmatched we have very little issues with compiles and running out of memory.
<davidlt[m]> IIRC JH7110 actually supports 16GB RAM too, but not for LPDDR4. That has to be traditional DDR chips.
<davidlt[m]> So things are better once we can use those 64-core server units. That's still at least months away.
esv_ has joined #fedora-riscv
esv has quit [Ping timeout: 255 seconds]
<davidlt[m]> Approaching 120 hours for GCC 13 build. This is where we lost it last time.
<neil> Yeah the plan is to mix vf2 and Unmatched... and then down the line: P550
<davidlt[m]> neil: do not forget TH1520 Sipeed stuff (if upstreaming goes well).
<neil> ah yeah, good call.. i will put that on my list
<davidlt[m]> That might be ~4 times faster than Unmatched, cheap, and 4G/core RAM.
<neil> btw i am starting to put together a one-pager on the state of uarch optimization in DNF/RPM, and trying to get a better handle on the work still needed to be done and/or proposed
esv has joined #fedora-riscv
esv_ has quit [Read error: Connection reset by peer]
<davidlt[m]> For RISC-V (and probably other stuff) the easiest thing is to just rebuild for RVA20/22/23 and x86_64-v2,3,4.
<davidlt[m]> At that point it's just a hardware question.
<neil> i'm interested in dnf being able to install the right rpm w/o the user needing to touch much (if anything)
<davidlt[m]> So RPM can detect x86_64 stuff now. glibc detects it and does the whole glibc-hwcaps thing.
<neil> also may have also figured out how to compile against x86-v3 on Rocky 8 which is only a bit cursed ;)
<davidlt[m]> If we rebuild everything it's just for the user to pick the right distro image to install (or the installer to do the detection and pick the right repo).
<davidlt[m]> I want optimized stuff + vendor repos. Vendor will always want that. Either to provide packages that are not yet available in the distributions or because they can tune the crap out of it on their target (uarch).
<davidlt[m]> I just don't like that user doesn't get a feedback (if vendor lock is on) that there are newer NVRs without vendor lock (I guess). Basically there is nothing make to sure vendor doesn't ship OpenSSL that is X months old.
<neil> yeah that is.. not ideal.
<neil> i think the vendor repos is a good approach
<davidlt[m]> Most of that is in already (expect a couple commands don't run with vendor lock on, vendor lock is not on by default and dnf cannot tell if there is a newer NVR for vendor lock package).
<davidlt[m]> Basically I think running resolver with vendor lock on and off should be enough. If there is a newer NVR compared to what we get with vendor lock then vendor is probably falling behind.
<neil> right, and the user can be alerted or, something
<davidlt[m]> DNF could spit a warning stating that there is a newer NVR if vendor lock would be removed.
<davidlt[m]> Actually knowing that newer NVR + repo would be nice to know.
<neil> >Disabling vendor lock for REPO would result in updating NVRA TO NVRA'
<neil> or so
<davidlt[m]> Like:
<davidlt[m]> Warning: newer NVR openssl-libs-3.0.5-3.fc37.x86_64 (from fedora repo) if vendor lock is disabled.
<davidlt[m]> Something like that (it's Sunday evening, head is not in working mode).
<davidlt[m]> The problem is with packages that are replacing OS vendor package.
<davidlt[m]> Also there would be a problem with error reporting.
<davidlt[m]> Like should Fedora/CentOS Stream/Rocky/etc. get error reports if a vendor package is invovled?
<neil> ah yeah, that could get confusing
<davidlt[m]> Imagine that 90% of all bug reports are coming from vendor because it broke something, didn't do enough QA, etc.
<davidlt[m]> It's not something Fedora (or other distro vendor) should actually fix.
<neil> right
<davidlt[m]> > RPM packages in a third-party repository must not replace packages provided by official Fedora repositories, nor break dependencies between those packages.
<davidlt[m]> RPM Fusion replaces system packages (at least a couple of them). RPM names do not conflict (I checked some, not all of them).
<davidlt[m]> > Duplicates and replacements
<davidlt[m]> >
<davidlt[m]> > Third-party repositories can supplement official Fedora software. In limited cases, they can be used to replace software included in the official Fedora repositories. Such situations require FESCo approval.
<davidlt[m]> Regarding optimized binaries (if we want a proper full thing, instead of glibc hwcaps) the easiest solution is rebuilding a full distro, having different ISOs. Better for the installer to check hardware, ask user if he/she wants optimized distribution (and in general user should have a way to pick which one).
<davidlt[m]> Once installed user would never need to deal with it.
<davidlt[m]> Full distro (incl. executables) are optimized (which is not the case with glibc hwcaps).
<davidlt[m]> I think Arch Linux actually has full repos.
<davidlt[m]> I don't really want to change baseline. That's number #1. Baseline doesn't change.
<neil> i am in agreement that it should be opt in
<neil> different ISOs I agree would be best, as well.. though i can imagine that could cause similar QA headaches
<davidlt[m]> Also there might be less bugs (unexpected ones) if we avoid mixing binaries (technically it's all fine, but who knows).
<neil> a meta installer that downloads the right ISO for you :)
<davidlt[m]> All the other (i.e. minimal or/and incremental) approaches are mostly because of storage issues, lack of hardware for builders, lack of hardware for CI gating, etc.
<davidlt[m]> For me (only know, until things merge into Fedora proper) rebuilding Fedora for RVA20/22/23 is a cheaper option.
<neil> makes sense to me.. should be easy to split those out for Composes
<davidlt[m]> Hardware in general is cheaper compared to engineering hours.
<davidlt[m]> Thus realistically one should look for a solution that makes it simpler and minimizes engineering hours.
<neil> exactly: min/max engineering hours and solving defined problems
<davidlt[m]> Bu that's my point of view (which could be completely wrong, or/and might change in the future during discussions).
<davidlt[m]> For example I don't know what Rocky Linux users, vendor and community is thinking about it.
<davidlt[m]> Well I know vendors would prefer: rebuild everything with -march=<uarch>! // Not realistic.
<davidlt[m]> Per-arch benefits are also different. I expect significant performance loss between different RISCV profiles. Way more compared to x86_64 -> x86_64-v3.
<davidlt[m]> Especially once run-time extensions start landing (like pointer masking/tagging). OpenJDK, Golang, Firefox, V8, etc.
<davidlt[m]> All the crypto extensions, random number stuff.
<davidlt[m]> Not to mention bit manip alone will give a nice boost. Especially if combined with vector.
<neil> I also wonder how much benefit there is from just a few select packages being rebuilt and overlayed. rebuilding everything is, as you say, a big ask.. but if there is some small percentage that truly benefit from optimization, perhaps those can be targeted
<davidlt[m]> Not really, rebuilding everything is easier. Hopefully it's mostly a hardware question.
<davidlt[m]> But yeah typical targets are glibc, openssl, gnutls, math/vector libraries (BLAS, etc.)
<neil> that is sorta what i expected on both sides. less complicated to just build it all and not mix
<davidlt[m]> So it's just a hardware problem.
<davidlt[m]> From my experience: it's easy to get more hardware, but it's really hard to get funding to hire someone.
<neil> capex is indeed usually cheaper
ahs3 has quit [Remote host closed the connection]
davidlt__ has quit [Ping timeout: 256 seconds]
ahs3 has joined #fedora-riscv