5 ms·
The title "Intel disables hardware lock elision on all current CPUs" seems too broad. Intel is disabling the backward ISA compatible implicit HLE capability--I
by wahern 7y ago
The title "Intel disables hardware lock elision on all current CPUs" seems too broad. Intel is disabling the backward ISA compatible implicit HLE capability--I can't remember exactly how it worked without looking it up, but IIRC it was a hack that leveraged existing cache coherency and ISA semantics to permit optimized spin-lock implementations that without feature detection still worked correctly on older chips.
Explicit TSX instructions are now merely opt-out, where previously they couldn't be disabled by the kernel. The posted patch doesn't seem to disable it but simply adds some of the bits needed to do so.
EDIT: Okay, I guess it is disabling Hardware Lock Elision (HLE), proper. But "hardware lock elision", lower case, implies all TSX-based lock elision code will stop being optimized. AFAIU RSX (explicit TSX) is usually only used for lock elision, anyhow; it's more of a microcode and speculation hack than a generic transactional memory feature, so the dividends quickly become elusive for anything beyond lock elision.
- my123 7y ago> The other TSX sub-feature, Hardware Lock Elision (HLE), is unconditionally disabled by the new microcode but still enumerated as present by CPUID(EAX=7).EBX{bit4}, unless disabled by IA32_TSX_CTRL_MSR[1] - TSX_CTRL_CPUID_CLEAR. Disabling HLE makes the code still works because of the backward ISA compatibility... but you still lose the performance benefits of HLE. Also, disabling it but still keeping it shown in CPUID...
- saagarjha 7y agoSo if I'm understanding this correctly, xacquire/xrelease now unconditionally fall back to being interpreted as the (useless) repne/repe prefixes, even on chips that "support" HLE?
- my123 7y agoYes...
- the-dude 7y agoIs anything know about how much performance will be lost?
- NicoJuicy 7y agohttps://twitter.com/damageboy/status/1194751035136450560?s=19 https://twitter.com/damageboy/status/1194751035136450560?s=1... Up to 20% for Array.Sort
- asveikau 7y agoWhy would Array.Sort have locking in need of elision? [I'm reminded of the old Java "Vector" or "StringBuffer" that put a lock around every operation "because thread safety is good" which had high cost for single threaded usage. But this is likely not what this is about.]
- makomk 7y agoWell, judging from the Phoronix benchmarks, performance is worse than just outright disabling TSX in its entirety: https://www.phoronix.com/scan.php?page=article&item=zombieload-v2-taa&num=1 https://www.phoronix.com/scan.php?page=article&item=zombielo... (Though they show basically no performance benefit from TSX, so...)
- YayamiOmate 7y agoI concur. I wondered whether their patch hit AMDs as well. Unlikely, but not entirely impossible, at least to me after hearing news about Linus "commenting" on their practices of creating problems for everyone.
- my123 7y agoAs far as I know, HLE is not implemented on AMD processors. However, part of the fix for JCC (https://www.intel.com/content/dam/support/us/en/documents/processors/mitigations-jump-conditional-code-erratum.pdf https://www.intel.com/content/dam/support/us/en/documents/pr... ) to recover the performance loss will make other CPUs slower if separate executables aren't used for unaffected CPUs... which they won't. > The MCU prevents jump instructions from being cached in the Decoded ICache when the jump instructions cross a 32-byte boundary or when they end on a 32-byte boundary. In this context, Jump Instructionsinclude all jumptypes: conditional jump (Jcc), macro-fusedop-Jcc(where opis one ofcmp, test, add, sub, and, inc, ordec), direct unconditional jump, indirect jump, direct/indirect call, and return The workaround to lower perf loss of having jumps uncached when they are on a 32-byte boundary involves adding quite some nops... (or padding with meaningless prefixes)
- saagarjha 7y agoLooks like the impact is pretty bad in certain cases: https://twitter.com/damageboy/status/1194751035136450560 https://twitter.com/damageboy/status/1194751035136450560
- my123 7y agoYeah, edited the title to uppercase Hardware Lock Elision now.
- temac 7y agoGood to avoid any misunderstanding, even if I don't think there should have been some: hardware lock elision is hardware lock elision, and TSX is not limited to hardware lock elision. So Intel disabled hardware lock elision, really, and the locks are not longer elided... Now maybe some people also like to elide some locks thanks to explicit RTM, but that's up to them, and that's not even completely hardware in this case (you have to write your own algo to do that and provide an explicit soft fallback), and of course Intel is not going to analyse algorithms to determine if there is logically some lock elision in a transnational section or not, and to only break out of speculation on the blocks of code presenting some...