Intel sticks another nail in the coffin of TSX with feature-disabling microcode update Intel has officially sounded the death knell for Transactional Synchronisation Extensions (TSX) on a selection of processors from Skylake to Coffee Lake – a security-enhancing move which will have an oversized performance impact on certain workloads. TSX was launched by Chipzilla in 2013 on selected Haswell processors. The …
Am assuming probably greater than 90% of workloads never use TSX, but am curious can anyone name an application or type of workload that did? I came across this blog post that explains what TSX is https://software.intel.com/content/www/us/en/develop/blogs/transactional-synchronization-in-haswell.html But to my brain it doesn't give me any clues as to being able to name a software application that might take advantage of it.
Some kind of database? HPC maybe? media encoding? super obscure custom in house apps?
From the sound of it it's hardware accelerated locking so a bunch of changes to shared memory all appear to other cpus to have changed as a single atomic operation. You can code begin and commit for changes in shared memory as you would for an SQL transaction.
Could be handy, except when hardware support is not there, you need to write alternative locking code yourself anyway, and it didnt really work :(
I can think of a few applications. A big contentious memory cache that occasionally has small changes.
A rules engine where occasionally a rule changes and you don't want to stop the world.
Seems like the sort of trick generally useful in servers.
libc - the bloated one made use of TSX for Haswell/Broadwell. Not sure if anyone bothered since.
Can someone explain me how something invented in the 90s can be totally ruined by Craptel in the 10s?
I have heard some old timers say that microcode used to fix and add features to some CPUs - whereas Craptel just crippled the crap out of them - rendering them obsolete pieces of sand.
Apparently, TSX has been ruined from some time https://www.ipetitions.com/petition/make-intel-pay-for-its-mistakes
I don't think that your 32 cores could fly along and commit memory across a number of 2M (or 4K) pages and then hope that your hardware could say -oopsies that memory has already been invalidated, so ABORT the BEGIN transaction. Its good to look at what the original uses were and the history https://en.wikipedia.org/wiki/Transactional_memory.
In theory, a lot of things could possibly have used it. Many things that use multiple cores for parallelism, anything that vaguely resembles a database. Don't think "TSX competes with SQL begin/commit/rollback". Instead think "TSX competes with LOCK CMPXCHG & friends for in-memory data structures".
For actual applications, I can't find much online. Apparently a PS3 emulator called RPCS3 used it, Oracle DB, SAP HANA, some HPC workloads.
You could also use it to make a faster version of mincore(), but that function is kind of useless anyway. ;)
It feels like a shame because limited hardware transactional memory was one of the more interesting recent-ish developments in CPUs.
Could go either way. Some of these changes permanently rewrite the microcode, some just until restart, some until power cycle.
But note the use of the term "default". This looks like a fail-safe situation where users will have the ability (presumably in the OS) to turn it back on. That rules out certain classes of changes.
Most modern operating systems (Windows, Linux, MacOS) load the microcode (and do the updates) automatically. This is done, every time the system restarts (volatile).
In theory, you can also update microcode from the BIOS/UEFI during boot. But, except for some odd cases, this is pointless. As previously stated, the operating system already does the trick. Therefore, what the BIOS does is irrelevant (and you can skip those updates).
They are disabling TSX by default, so presumably there is a way to enable it again if you are willing to take the security risk.
If that is the case, forget any refunds, cos the feature is still there - you just have to enable it if you want it, and are willing to take the risk.
Intel has historically very rarely offered refunds or recalls for faulty hardware. They refused to offer refunds for the previous TSX faults in Haswell chips. I *think* the Pentium FDIV bug was the last time they offered replacements for faulty chips. There have been a lot of errata in a lot of Intel CPUs since then.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
