Add native RISC-V nodes to OMR CI testing #7530
Comments
|
https://github.com/eclipse-cbi/jiro/wiki/Dedicated-build-agents
Generally we use the openj9 playbooks to setup omr machines because that is a superset of the tools needed for OMR builds. Do we have a minimal set of tools required documented somewhere? Perhaps we can craft our own container that eclipse will host for us. Alternatively we can install the necessary tooling in the container on the fly but that will require a bit of build work to get going. For the record, we have riscv builds that run in qemu(?) on x64 linux. They have been disabled since May 2024. I cannot recall why exactly. Looks like the 2 machines that can run those were offline for a while. When the builds were running they were taking about an hour to complete. I have kicked off a build to see if it still works. https://ci.eclipse.org/omr/job/Build-linux_riscv64_cross/494/ |
They were consuming a lot of memory and were falling over intermittently. I thought there was an issue created for this, but can't find it at the moment. What I recall, the harness running the OMR compiler during test is leaking memory between compilations. While there are hacks to fix this, as we discussed somewhere the preferred way to fix it is to understand all the holes and plug them. |
|
These builds were disabled because they were unreliable. The exact cause was never found, but my suspicion is excessive memory consumption caused by some interference with OMR's code cache and QEMU's TCG. |
|
Here's what I installed on my RISC-V machines in order to compile and test both OMR and OpenJ9: https://github.com/janvrany/debian-for-toys/blob/master/common/mk-fs-hooks/customize50-dev-tools.sh But the list above is not minimal. @jdekonin wrote a Dockerfile used to build cross-compilation environment that was used in the - now disabled - builds. Here's the relevant bit: https://github.com/eclipse-omr/omr/blob/master/buildenv/docker/riscv64/debian11/Dockerfile#L81 Note, that you need |
|
Do we expect real hardware to be more reliable then since it won't be using qemu? |
I would, but I never hard problem with QEMU either (but the machine had/has 16GB RAM). Speaking if RISC-V hardware, I have the exact same board for some time and never had that kind of problems (was running jobs on it since "old" job was disabled just have a feeling if things are still okay). I'm not running it now because |
|
It seems that RISC-V node is connected: https://ci.eclipse.org/omr/computer/riscv-build2/ Is there anything I can do to make use of it? |
|
We likely want to add a new spec to the jenkins file that isn't omr/buildenv/jenkins/omrbuild.groovy Line 163 in ef89b64 I can add new builds to Jenkins. The new spec won't be happening in Docker so don't add it to this line https://github.com/eclipse-omr/omr/blob/ef89b64bcaf398492b7c748135b226ccbf76940b/buildenv/jenkins/omrbuild.groovy#L47C2-L47C56 For the machine label I would use hw.arch.riscv64
|
|
@AdamBrousseau I have added the spec as suggested, see #7556. I cannot really test it though (or do not know how). |
|
@AdamBrousseau it seems that RISC-V agent fails randomly, see
but this is okay: Any idea? |
Eclipse now provides limited access to native RISC-V nodes, upon request. Details here [1].
We will have to evaluate whether these are suitable for native builds and test, or just as test nodes.
[1] https://github.com/eclipse-cbi/cbi/wiki#whats-provided
@janvrany @AdamBrousseau @jdekonin FYI
The text was updated successfully, but these errors were encountered: