By: sr (nobody.delete@this.nowhere.com), April 3, 2021 12:39 pm
Room: Moderated Discussions
Linus Torvalds (torvalds.delete@this.linux-foundation.org) on April 3, 2021 12:14 pm wrote:
> sr (nobody.delete@this.nowhere.com) on April 3, 2021 11:30 am wrote:
> >
> > But whole idea of transactional memory isn't saved cycles from locking - main point
> > is to let other threads to use all cachelines that aren't modified by transaction.
>
> No.
>
> The main idea of transactional memory is to improve performance.
Yes, and it tries to achieve that with memory that can be modified atomically without software locking.
>
> Yes, it does so by avoiding bouncing cachelines (and that is mainly by keeping them shared).
Nope, it does it by affecting only cachelines that are modified. And TSX does it by "sneaky", if anybody doesn't notice shared memory can be modified. So whatever your transaction size is, it can be executed succesfully only it no other thread reads any of that data. There's other ways to do transactional memory but Intel's doesn't need any modifications to actual critical section code if it fits in hardware limits.
>
> But one is fundamental (performance) and one is just a tool to get there (avoid dirtying cachelines).
It's not about dirtying cachelines, it's about sharing critical section data. If locked structure's data keeps 99.999% unmodified and only 0.001% data changes other threads can keep executing and transaction only fails if other core reads that minor data area. Transactional memory isn't universal solution to all locking problems but it can make concurrent execution happening where it can't be easily done with traditional locking schemes - or at least makes programming easier.
> sr (nobody.delete@this.nowhere.com) on April 3, 2021 11:30 am wrote:
> >
> > But whole idea of transactional memory isn't saved cycles from locking - main point
> > is to let other threads to use all cachelines that aren't modified by transaction.
>
> No.
>
> The main idea of transactional memory is to improve performance.
Yes, and it tries to achieve that with memory that can be modified atomically without software locking.
>
> Yes, it does so by avoiding bouncing cachelines (and that is mainly by keeping them shared).
Nope, it does it by affecting only cachelines that are modified. And TSX does it by "sneaky", if anybody doesn't notice shared memory can be modified. So whatever your transaction size is, it can be executed succesfully only it no other thread reads any of that data. There's other ways to do transactional memory but Intel's doesn't need any modifications to actual critical section code if it fits in hardware limits.
>
> But one is fundamental (performance) and one is just a tool to get there (avoid dirtying cachelines).
It's not about dirtying cachelines, it's about sharing critical section data. If locked structure's data keeps 99.999% unmodified and only 0.001% data changes other threads can keep executing and transaction only fails if other core reads that minor data area. Transactional memory isn't universal solution to all locking problems but it can make concurrent execution happening where it can't be easily done with traditional locking schemes - or at least makes programming easier.
