[Info-vax] The attempts to keep Linux on Itanium (attempt number 0x7fff_ffff)

[Jake Hamby (Solid State Jake)]

On Tuesday, November 21, 2023 at 3:01:42 PM UTC-8, Single Stage to Orbit wrote:
> On Tue, 2023-11-21 at 18:36 +0000, Simon Clubley wrote: 
> > There's been another batch of moaning from some people wanting to 
> > keep Linux running on Itanium: 
> > 
> > https://www.theregister.com/2023/11/21/saving_linux_on_itanium/ 
> > 
> > My question is _WHY???_ are people still wanting to run Linux on 
> > Itanium for goodness sake ? 
> > 
> > Unlike other obscure architectures that Linux runs on, you can't 
> > even emulate Itanium systems in a full-system emulator - you need 
> > the actual expensive, noisy, power-hungry, etc, hardware to run it 
> > on.
> I suspect it might be just possible to emulate the hardware on today's 
> machines but one would need their head examined. 
> -- 
> Tactical Nuclear Kittens

You can’t emulate Itanium fast enough in software with any known emulator that’s available to the public and is capable of running the Linux kernel. There’s only a very old partial software emulator called ski.

There’s the even rarer Itanium 1 that people keep around to run the very old canceled Itanium OSs like the SCO/AIX hybrid “Project Monterey” if I’m remembering the YouTube lore. My own HP rx2620 boxes are power-heavy boat anchors that I’d like to sell (1 working dual 2x 1.6 GHz Itanium2 plus 2 more identically configured blades for parts, plus Ultra320 drives + Compaq RAID controller).

You can just barely run OpenVMS and HP-UX on such a system from 2004, and Gentoo Linux at least will run self-hosted with “~ia64” (as with Alpha, only the experimental “~” USE type is supported), but it has nothing to redeem it unless you’re seriously into register windows and “not a thing” bits). I’m surprised the toolchain and the kernel are stable with the default compiler flags in Gentoo. None of the BSDs care about it any more.

The Alpha is more interesting, easier to understand, runs VMS much better, is vastly easier to emulate, and has the distinction of being the production shared-memory SMP architecture that’s the most notorious for the CPUs being allowed to do the most reordering of reads and writes relative to what’s seen from other cores, and doing so.

Consequently, while my Compaq XP1000 and PWS 600au can also just barely run OpenVMS, Tru64 UNIX, and Linux, the EV67 in the XP1000 has the latest and greatest hardware perf counters which Linux “perf” knows about, and the SMP variants of the EV67 and newer would be worthwhile to have in a very thorough Linux kernel or distro CI/CD pipeline if you want to try to catch breakage of read/write dependencies that Alpha requires explicit barriers for.

ARM and most other RISC are somewhere in the middle as far as load and store ordering (and I think Itanium as well?) while x86 and s390x are on the far end of guaranteeing that CPUs see loads and stores in chronological order and many memory barriers convert to nops, which is why it’s nice that the C11 and C++11 stdatomic functions allow you to explicitly state your use of atomic variables so it will hopefully even run on Alpha.

I’m about to test this on my vintage systems with the new local event flag code I finally finished writing for libuv that I can use as a base for converting the socket and eventually other calls from thread pool and poll() to sys$qio and AST callback. I’m getting 12,000 msgs/sec for the async1 benchmark and 18,000 for async2, then it falls back to 12,000 for async 4 and 6,000 for async8, but the results are at least “not crashing” and “not 3k/sec” like I was seeing earlier today.