By: David Kanter (dkanter.delete@this.realworldtech.com), March 31, 2021 8:37 pm
Room: Moderated Discussions
Linus Torvalds (torvalds.delete@this.linux-foundation.org) on March 31, 2021 4:44 pm wrote:
> With the constrained version, you also don't end up needing the "transaction predictor"
> logic that I personally am convinced is required for the generic lock elision case.
>
> That said, I have this dim memory of the zSeries retry mode being "go very very slow". So I don't know
> how well it works in practice if you actually have conflicts. Again, I haven't actually used the zSeries
> version, but I can very much believe that the constrained TM model is very useful in specialized libraries
> and/or for people who have some very hot and simple case they can code specially for it.
The zArch version of HTM does have forward progress guarantees. However, to deliver those guarantees, the CPU can do all sorts of fun things during fallback - e.g., reducing issue width down to 1 instruction, disabling out-of-order execution, etc.
So it will make forward progress, but it could be slow!
> And all the transactional memory models - including the constrained version - have a fundamental issue with debugging
> and things like single-stepping. But admittedly so does load-locked / store-conditional, and it hasn't been a
> huge issue. Again, the issue is much less in the constrained model than it is in the general case.
>
> But at the same time it obviously isn't that holy grail of big lock elision to make it easy
> to write scalable threaded software. Which nobody has actually really gotten to work.
Yes, I'm also a bit sad and disappointed. I think one real problem is that your speculative regions become quite large and expensive to rollback. Also, many workloads do have frequent interrupts, etc.
David
> With the constrained version, you also don't end up needing the "transaction predictor"
> logic that I personally am convinced is required for the generic lock elision case.
>
> That said, I have this dim memory of the zSeries retry mode being "go very very slow". So I don't know
> how well it works in practice if you actually have conflicts. Again, I haven't actually used the zSeries
> version, but I can very much believe that the constrained TM model is very useful in specialized libraries
> and/or for people who have some very hot and simple case they can code specially for it.
The zArch version of HTM does have forward progress guarantees. However, to deliver those guarantees, the CPU can do all sorts of fun things during fallback - e.g., reducing issue width down to 1 instruction, disabling out-of-order execution, etc.
So it will make forward progress, but it could be slow!
> And all the transactional memory models - including the constrained version - have a fundamental issue with debugging
> and things like single-stepping. But admittedly so does load-locked / store-conditional, and it hasn't been a
> huge issue. Again, the issue is much less in the constrained model than it is in the general case.
>
> But at the same time it obviously isn't that holy grail of big lock elision to make it easy
> to write scalable threaded software. Which nobody has actually really gotten to work.
Yes, I'm also a bit sad and disappointed. I think one real problem is that your speculative regions become quite large and expensive to rollback. Also, many workloads do have frequent interrupts, etc.
David
