3 ms·
You can’t simplify the logic because TSX transactions may abort for any reason and make no promises of forward progress. You must implement a fallback codepath.
by jdsully 7y ago
You can’t simplify the logic because TSX transactions may abort for any reason and make no promises of forward progress. You must implement a fallback codepath.
If you meant having an optimized codepath then that is doable. But given your writing a kernel there may be microarchitectural hazards that trigger excessive aborts.
- amluto 7y agoForget microarchitectural issues. If you have user memory paged out (or not present for accounting reasons, etc), you can try to access it in a transaction until the cows come home and it will never work — to make progress, you need to update the page tables either via a page fault or manually.
- roblabla 7y agoNot an issue for me, my kernel has no swap or other such thing - by design. Of course I realize not everyone is in my shoes - such an approach would absolutely fail on Linux!
- roblabla 7y agoYeah, at first I wanted to use TSX exclusively, but I came to the same conclusion you did while digging into it more deeply. I still think having a fast path using TSX could be useful, but since I never had a CPU with it, I never had a chance to benchmark it.
- saagarjha 7y ago> I still think having a fast path using TSX could be useful That’s what TSX is intended to be: a path that runs faster when possible.
- jdsully 7y agoIn some cases it can have a huge speedup. But it's rather tricky to get right. So far for almost all of my use cases the transaction sizes have been too large, and it almost always aborted. The RPCS3 PS 3 emulator saw a 40% perf boost so some amazing gains are possible. https://www.phoronix.com/scan.php?page=news_item&px=RPCS3-Intel-TSX-Support https://www.phoronix.com/scan.php?page=news_item&px=RPCS3-In...