Another excellent analysis by Hugo Landau (using findings from Jim Donoghue) on the presence — and accessibility — of hardware-supported tagged memory in the POWER9, even bare-metal POWER9s like ours. Operating systems like IBM i (formerly OS/400) use tagged pointers on every quadword for security purposes to mark pointers as valid, storing the tag data outside of the normal addressing space. If an invalid pointer is loaded, a trap instruction intercepts the fault. The instruction to set tags is undocumented and (apparently) privileged, and nothing other than IBM i currently uses it, but naturally that didn't stop these guys. Enabling tags active requires you set your POWER9 to big-endian and use the HPT MMU (i.e., the same configuration IBM i would run the CPU in). Hugo provides a detailed technical discussion on how they are accessed and stored, plus sample code (spoiler alert: the tag set instruction is 0x7c0103e6).
Posts
Firefox 106 on POWER
OpenBSD 7.2
The latest release of OpenBSD is available, the new 7.2. Although there are few, if any, Power-specific changes, there are many welcome general ones including multiple improvements in SMP and updated graphics and hardware drivers. LibreSSL and OpenSSH are also updated. Note that the powerpc64 port remains big-endian only — which I have to admit is lovely — and the changelog page only gives "XXXX" for number of prebuilt packages available for 32-bit powerpc and 64-bit powerpc64. Here is a complete list of changes and download mirrors.
More cores for Mesa llvmpipe
While various alternatives like Libre-SoC continue development, the only 3D solution right now for a system that wants to run entirely open is a software rasterizer like llvmpipe, and even though it supports ppc64le its performance has not been great historically on our systems — see my poor struggling 4-core Blackbird running Xonotic at 1080p on the right. Fortunately, a modest but noticeable improvement is landing which should help. Apparently there's a hard cap of 16 threads, meaning all but the smallest 4-core Blackbird and T2 Lite machines were going underutilized, so now the cap is raised to 32.
This doesn't double graphics performance: as a developer notes in the thread, there are other bottlenecks that serialize the output, so the effective improvement going from 16 to 32 on a system with sufficient threadroom is about 10%. Also, on a smaller system the renderer will only use up to the maximum number of threads available no matter what the cap is set to. Still, if you have the cores this gets you another frame per second or two, so that's not nothing. Best guess is this will come out as part of Mesa 22.3; props to Luke Dashjr, who noticed the hard cap, and Jeremy Rand, who got the patch landed to raise it.
The next logical question is how far to turn up the volume knob (or, alternatively, why there's a hard cap at all apart from not recruiting too many execution units when the improvement is expected to be minor). While I can't answer the second question, Jeremy is looking for someone who wants to try ramping the patch up to 176 threads, the maximum number of hardware threads available on a dual-22 system. Such monsters do exist in the hands of enthusiasts, although it would also be good to see how it performs on smaller systems (regrettably my dual-8 is my daily driver or I'd try this already, so I'm deferring this until I have to mess with the guts again). If you're able to recompile your own local copy of Mesa with this change, post in the comments what you observe (there's a benchmark script on the Raptor wiki you can use to get the performance delta).
Linux 6.0
The Linux 6.0 kernel is out, formerly "5.20," and on its way to a distro near you. Keeping in mind that no Linux numerical release corresponds to any particular milestone, real or imagined, the marquee improvements include more graphics hardware support, XFS performance and scalability improvements (I like this in particular since my Fedora root is still XFS), further preparations for Compute Express Link, zero-copy send for networking and io_uring userspace block driver support.
On the PowerPC and Power ISA side this release is largely fixes, but notable new improvements are support for syscall stack randomization, a driver for the PowerVM Platform KeyStore, and atomic operations with the 32 and 64-bit BPF JITs. If you work on 64-bit Book3E hardware, now you also get full KASAN.
As a postscript in the no-country-for-old-hardware dept., support was withdrawn for the NEC VR4100 MIPS CPU family, which among other systems powers the IBM WorkPad z50 and the Agenda VR3 Linux PDA, and support for VMEbus was moved to staging with the threat to remove it entirely if there's no maintainer. Sadly won't be me since I don't have any VME hardware currently.