All these performance neutering patches, made in the name of 'security' that in certain situations has no value whatsoever, should only be accepted if also conditioned by the "mitigations=" Kernel boot option.
From the article:
> A memory ordering issue is what is reportedly leading Intel to now deprecate TSX on various processors.
And from the Intel document linked in the article:
> The default RTM force-abort behavior can be optionally disabled by setting MSR bit TSX_FORCE_ABORT.SDV_ENABLE_RTM=1. However, when RTM force abort is disabled in this way, RTM usage may be subject to memory-ordering correctness issues. Due to these issues, this unsupported mode should not be enabled for production use.
With Intels wave of TSX disabling patches going over all the previous CPU generations, AMD apparently got it right by never bringing their own version into production at all.
How would you get memory protection or debugger support then?
Or the very-likely use-case of rendering live (i.e. untrusted) web-content in-game? That would require a modern engine like Chromium which in-turn necessitates per-process isolation.
Also, no-one wants to have to reboot their entire computer system just because some application code crashed. Even if preemptive scheduling and the MMU works in ring 0 all processes in ring 0 can manipulate the MMU registers, so a misbehaving process can still bring down the entire system. Bad idea.
Even dedicated HPC applications need it - remember that the HPC/scientific-computing/batch-job-processing model is the whole reason that operating-systems exist today: they're highly evolved successors to job-control programs (e.g. Chippewa Operating System). So I don't think they'd want to give up all the improvements of the past 50+ years.
Ultimately we're just arguing about the principle of how the user who owns the computer should be in ultimate control over the hardware - but unfortunately Apple has demonstrated that principle is unnecessary to make obscene profits and also runs contrary to the realities of running a large secure platform today. We shall see how this ends-up...
The root user still can access read/write the whole memory of the system anyway via /dev/mem, load kernel modules, and do practically anything on the system. In that context, a change of privilege is useless in practice, and can lead to performance degradation.
This will lead performance benefits in most system daemons, notably programs that interact closely with the kernel like systemd.