Slashdot Mirror
Errata Prompts Intel To Disable TSX In Haswell, Early Broadwell CPUs
Dr. Damage writes: The TSX instructions built into Intel's Haswell CPU cores haven't become widely used by everyday software just yet, but they promise to make certain types of multithreaded applications run much faster than they can today. Some of the savviest software developers are likely building TSX-enabled software right about now. Unfortunately, that work may have to come to a halt, thanks to a bug—or "errata," as Intel prefers to call them—in Haswell's TSX implementation that can cause critical software failures. To work around the problem, Intel will disable TSX via microcode in its current CPUs — and in early Broadwell processors, as well.
So, basically, they've just been forced to get rid of the most complex (that's why it's not all that surprising) yet also most beneficial feature with regards to server loads? I'm sure there are some Opterons laughing right now.
Ezekiel 23:20
"Featurata"
In some countries I would be entitled to get the product that was advertised or get a refund.
You either say "bugs - or errata" or "a bug - or erratum", since bug is singular and errata plural. At least the error - or "erratum" (see what I did here) in this case was in TFA and not introduced in the /. summary.
Violence is the last refuge of the incompetent. Polar Scope Align for iOS
It would have been nice if TFA had told us what chips were affected, or how to determine that, rather than saying "haswell" and expecting everybody reading it to do their own research.
I just spent ten minutes looking around the web, trying to determine if the processor in my laptop is one of those affected - preperatory to perhaps trying to figure out, if it is, how to apply the "disable the broken feature" fix - without installing windows - to avoid the memory corruption bogyman if somebody distributes software that uses, or abuses the feature.
No joy. The documentation seems to say that:
- Core i7 is Haswell
- TSX is NOT supported on versions up to somethng BEFORE the processor version in my laptop (i7-4700MQ)
- But the descriptions of that processor I've found so far don't say, one way or another, whether it does or doesn't have TSX. B-b
The "flags" field in /proc/cpuinfo doesn't include a "tsx". But would it?
Can anyone tell us a simple way to check?
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Check the Intel ARK page for your model number Ex: http://ark.intel.com/products/...
Can anyone tell us a simple way to check?
Intel has on their website info on the processors.
For example, for yours (i7-4700mq) you would look at:
http://ark.intel.com/products/75117/Intel-Core-i7-4700MQ-Processor-6M-Cache-up-to-3_40-GHz
Or you can look for all products that were "formerly haswell":
http://ark.intel.com/products/codename/42174/Haswell#@All
how to apply the "disable the broken feature" fix - without installing windows
I would do some searches for updating BIOS from linux - ex:
https://wiki.archlinux.org/index.php/Flashing_BIOS_from_Linux
Or doing a microcode update:
https://wiki.archlinux.org/index.php/Microcode
Until there is a chip for sale that really supports TSX I wouldn't expect anyone to be distributing software that uses it. So I wouldn't be too worried about it yet.
Wikipedia has very detailed information on Intel processors. This page does not list TSX for your processor and does list it for others.
Most Linux distros automatically handle Intel microcode patches (which I assume is how this errata will be handled). See Debian wiki or Arch wiki for details.
ARK is your friend if you don't have the CPU. dmesg, kernel boot showing feature flags, or CPU-id or whatever the windows app is will all tell you what your CPU supports.
Your Linux box will probably just have an update with new microcode for the issue and you'll never need to know anything about it, or it will fiddle with the cpu flags to show it as disabled anyway.
Basically 'if you don't know, it doesn't affect you'
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
You can still "play with this instruction" all you want.
What happened here is that a third party developer managed to uncover a corner case where certain interactions with TSX can lead to instability. In order to be safe, Intel acknowledged the bug (a refreshing response) and is now giving you the OPTION to disable TSX if you feel that it could impinge the stability of a production load.
So basically: Go ahead and play with TSX all you want, but be aware of the errata and that it's theoretically possible to hang your machine in some corner cases.
AntiFA: An abbreviation for Anti First Amendment.
This is a real pity for the TM community. This is not the first chip with transactional memory support in hardware: The Sun Rock was announced to have hardware TM support, and the IBM Blue Gene/Q Compute chip also supports it. Unlike other proposals for unbounded transactional memory, all these systems employ Hybrid Transactional Memory (ref, ref, ref), in which restricted hardware transactions are designed to correctly coexist with unbounded software transactions, so a software transaction can be started in case a hardware transaction fails for some unavoidable issue (such as lack of cache size or associativity to hold speculative data from the transaction, not because of a conflict). Note that, in any case, very large transactions should arguably be very uncommon, since they would significantly reduce performance (similar to very large critical sections protected by locks).
The problem with the hardware implementation of transactional memory is that they are not simply a new set of instructions which are independent from the rest of the processor. HTM implies multiple aspects, including multiversioning caching for speculative data; allowing for the commit of speculative (transactional) instructions, which could be later rolled back (note that in any other speculative operation such as instructions after branch prediction, the speculation is always resolved before instruction commits because the branch commits earlier); a tight integration with the coherence protocol (see LogTM-SE for an alternative to this very last issue, but still...); a mechanism to support atomic commits in presence of coherence invalidations... From the point of view of processor verification, this is a complete nightmare because these new "extensions" basically impact the complete processor pipeline and coherence protocol, and verifying that every single instruction and data structure behaves as expected in isolation does not guarantee that they will operate correctly in presence of multiple transactions (and non-transactional conflicting code) in multiple cores. There are some formal studies such as this or this, and the IBM people discuss the verification of their Blue Gene TM system in this paper (paywalled).
As some others commented before, the nature of the "bug" has not been disclosed. However, since it seems to be easy to reproduce systematically, I would expect it to be related to incorrect speculative data handling in a single transaction (or something similar), rather than races between multiple transactions.
Regarding the alternatives, Intel cannot simply remove these instructions opcodes because previous code would fail. I assume that the patch will make all hardware transactions fail on startup, with an specific error (EAX bit 1 indicates if the transaction can succeed on a retry; setting this flag to 0 should trigger a software transaction). In such case, execution continues at the fallback routine indicated in the XBEGIN instruction, which should begin a software transaction. Effectively, this will be similar to a software TM (STM) with additional overheads (starting the hardware transaction and aborting it; detecting conflicts with nonexistent hardware transactions) that would make it slower than a pure STM implementation.
That's different. I'll explain for the benefit of ESLers reading Slashdot:
The use of "a" or "an" in modern English is always conditioned by the phonology. The rule is that "an" becomes "a" when followed by a phoneme with a sonority below "vowel". Hence "a hedgehog" in standard or "an hedgehog" (pronounced "an edge Ogg") in voiced-aitch dialects such as Cockney. I've seen only one consistent exception to this rule: "an hero" referring to one who commits suicide, which retains "an" even in voiceless-aitch dialects.
By contrast, the reanalysis of a plural first as a mass noun and eventually as a singular referring to the collection is closer to morphology. The behavior of "errata" has loosely paralleled that of "data", which has already become a mass noun taking a singular (such as "the data is..."), with "datum" having become archaic in favor of "data point" or "piece of data". The step after a mass noun is a collective, which can lead to a double plural; "erratas" refers to what would be called "collections of errata" under the older convention.