> On Thu, Feb 20, 2020 at 04:55:12PM +1300, Thomas Munro wrote: > Hello hackers, > > Here's a *highly* experimental patch set that tries to skip the LWLock > protocol in predicate.c and use HTM[1] instead. HTM is itself a sort > of hardware-level implementation of SSI for shared memory. My > thinking was that if your workload already suits the optimistic nature > of SSI, perhaps it could make sense to go all-in and remove the rather > complicated pessimistic locking it's built on top of. It falls back > to an LWLock-based path at compile time if you don't build with > --enable-htm, or at runtime if a startup test discovered that your CPU > doesn't have the Intel TSX instruction set (microarchitectures older > than Skylake, and some mobile and low power variants of current ones), > or if a hardware transaction is aborted for various reasons.
Thanks, that sounds cool! > The good news is that it seems to produce correct results in simple > tests (well, some lock-held-by-me assertions can fail in an > --enable-cassert build, that's trivial to fix). The bad news is that > it doesn't perform very well yet, and I think the reason for that is > that there are some inherently serial parts of the current design that > cause frequent conflicts. Can you share some numbers about how not well it perform and how many hardware transactions were aborted with a fallback? I'm curious because from this paper [1] I've got an impression that the bigger (in terms of memory) and longer transaction is, the higher changes for it to get aborted. So I wonder if it needs to be taken into account, or using it for SSI as presented in the patch somehow implicitely minimize those chances? Otherwise not only conflicting transactions will cause fallback, but also those that e.g. span too much memory. Another interesting for me question is how much is it affected by TAA vulnerability [2], and what are the prospects of this approach in the view of many suggests to disable TSX due to that (there are mitigations ofcourse, but if I understand correctly e.g. for Linux it's similar to MDS, where a mitigation is done via flushing cpu buffers on entering the kernel space, but in between speculative access still could be performed). [1]: https://db.in.tum.de/~leis/papers/HTM.pdf [2]: https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/tsx_async_abort.html
