3 ms·

I've disliked the idea of TSX since the beginning. Having studied some circuit design, computer architecture, and operating systems in college, though I work in

I've disliked the idea of TSX since the beginning. Having studied some circuit design, computer architecture, and operating systems in college, though I work in user-space software now I do like to understand how all the layers beneath me work. TSX has always given me the heebie-jeebies. Sure it might give great performance uplift if you have a team of skilled scientists and engineers and servers dedicated to a single application. But for general computing, it's really crazy. Good for academic papers, good for marketing to the director level, bad for general engineering work. It turns out that it doesn't really work. Surprise! not really

alfalfasprout 5y ago
I'm not sure TSX was really intended to be used everywhere though. Admittedly the glibc team tried to use it in pthreads and it was a disaster (a lot of code broke and of course it kept getting disabled in CPUs). Their issue IMO was not really scoping down TSX... the project was far too ambitious.
- ploxiln 5y ago
  Intel employees added it to glibc. I think Intel wanted to show everyone "don't be scared, silly, you're already using it!" https://lwn.net/Articles/534761/ https://lwn.net/Articles/534761/ http://halobates.de/adding-lock-elision-to-linux.pdf http://halobates.de/adding-lock-elision-to-linux.pdf
lallysingh 5y ago
Why? The implementation sounded simple: bus snoop on addresses used by the load unit, invalidate if anyone writes to those lines.
- zozbot234 5y ago
  Like you say it's not addresses, it's implementation-dependant "lines" that may or may not be coincident with cachelines. False invalidations are absolutely a concern. (They're a concern already for CAS loops, which you need e.g. to do arbitrary read-modify-write on atomic-sized data. Hardware transactions only magnify these concerns.)
- ploxiln 5y ago
  But also, maintain a bunch of memory and cpu state invisibly, and apply a bunch atomically or roll it back, and do this for multiple threads simultaneously. And then try debugging some seemingly unrelated issue at the memory/instruction level, and drop the assumption that everything below your level of abstraction works perfectly as you expect. And yes, this is very similar to mis-predicted branches and the speculative execution vulnerabilities. I have honestly tried to understand those at the instruction level, and felt like I did at one point, and then a few months later felt like I forgot some key details and couldn't put it together again... like I get the idea, but can't quite put together the assembly to demo the problem on my own, it's a bit of a mindfuck ...

alfalfasprout 5y ago

I'm not sure TSX was really intended to be used everywhere though. Admittedly the glibc team tried to use it in pthreads and it was a disaster (a lot of code broke and of course it kept getting disabled in CPUs). Their issue IMO was not really scoping down TSX... the project was far too ambitious.

ploxiln 5y ago
Intel employees added it to glibc. I think Intel wanted to show everyone "don't be scared, silly, you're already using it!" https://lwn.net/Articles/534761/ https://lwn.net/Articles/534761/ http://halobates.de/adding-lock-elision-to-linux.pdf http://halobates.de/adding-lock-elision-to-linux.pdf

lallysingh 5y ago

Why? The implementation sounded simple: bus snoop on addresses used by the load unit, invalidate if anyone writes to those lines.

zozbot234 5y ago
Like you say it's not addresses, it's implementation-dependant "lines" that may or may not be coincident with cachelines. False invalidations are absolutely a concern. (They're a concern already for CAS loops, which you need e.g. to do arbitrary read-modify-write on atomic-sized data. Hardware transactions only magnify these concerns.)
ploxiln 5y ago
But also, maintain a bunch of memory and cpu state invisibly, and apply a bunch atomically or roll it back, and do this for multiple threads simultaneously. And then try debugging some seemingly unrelated issue at the memory/instruction level, and drop the assumption that everything below your level of abstraction works perfectly as you expect. And yes, this is very similar to mis-predicted branches and the speculative execution vulnerabilities. I have honestly tried to understand those at the instruction level, and felt like I did at one point, and then a few months later felt like I forgot some key details and couldn't put it together again... like I get the idea, but can't quite put together the assembly to demo the problem on my own, it's a bit of a mindfuck ...