Re: gem driver for sun4m

On Tuesday, July 14, 2026 6:58:34=E2=80=AFPM Eastern Daylight Time you wrot=
e:
> So far, it seems to be working out quite well. I'm able to get about the
> speeds you'd expect running with flash storage through a BlueSCSI and I
> haven't seen any issues with stability. I'm preparing a patch now pending=
 a
> regression test on sparc64. I'd appreciate feedback or testing from other
> port-sparc users, if there's any interest.

That took a lot longer than I thought it would, my apologies for the delay =
in=20
follow-up. In the end, I also wanted to double check my numbers for sparc.

Downloading seems to be consistently faster than uploading. Without TLS=20
overhead, both download and upload speeds scale pretty linearly with=20
frequency. Except when MP gets involved, and then at least on iperf3, it's=
=20
simply worse. Which I do find hilarious.

I ran several synthetic load tests with iperf3 to check the performance ove=
r=20
time. This was a mix of IPv4 and IPv6 with TCP traffic, as well as UDP at 3=
00=20
kbit/s and 4 Mbit/s, picked slightly arbitrarily. I also included some long=
er=20
runs (~5 minutes of sustained TCP). It all seemed very promising for=20
stability!

"Sunny"
170 MHz TurboSPARC, 256 MB of RAM
Up: 26.5 Mbit/s
Down: 30.1 Mbit/s

"Share"
85 MHz MicroSPARC II, 64 MB of RAM
Up: 12.3 Mbit/s
Down: 14.4 Mbit/s

"Saguaro"
125 MHz HyperSPARC, 512 MB of RAM
up: 19.1 Mbit/s
Down: 20.8 Mbit/s

2x 125 MHz HyperSPARC with MP kernel
Up: 13.7 Mbit/s
Down: 19.0 Mbit/s

I did want to test with the multiprocessor kernel as well, even though my=20
SS10's power supply struggles to run both of these modules for more than ab=
out=20
10-15 minutes. I don't think the gem driver made it any less stable, at lea=
st.=20
No regressions noticed on sparc64, either, which I was slightly worried abo=
ut.

The switch was a Catalyst 3508G-XL connected back to the rest of the LAN wi=
th=20
an SC to LC patch cable. The server was running iperf3 on amd64 and should=
=20
have been able to handle pretty well any traffic these machines could throw=
 at=20
it.

This is my first attempt at submitting a kernel patch, so I hope this is th=
e=20
correct way to go about it. The patch is under kern/60453

Erik