Re: Improving spin-lock implementation on ARM.

> On 01/12/2020, 16:59, "Alexander Korotkov" <aekorotkov(at)gmail(dot)com> wrote:
> On Tue, Dec 1, 2020 at 1:10 PM Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com> wrote:
> > FWIW, here is an earlier discussion on the same (also added the
> > proposal author here) :

Thanks for looping me in!

> >
> > https://www.postgresql.org/message-id/flat/099F69EE-51D3-4214-934A-1F28C0A1A7A7%40amazon.com
>
>
> Thank you for pointing! I wonder why the effect of LSE on Graviton2
> observed by Tsahi Zidenberg is so modest. It's probably because he
> runs the tests with a low number of clients.

There are multiple possible reasons why I saw a smaller effect of LSE, but I think an important one was that I
used a 32-core instance rather than a 64-core one. The reason I did so, was that 32-cores gave me better
absolute results than 64 cores, and I didn't want to feel like I could misguide anyone.

The 64-core instance results is a good example for the benefit of LSE. LSE becomes most important in edges,
and with adversarial workloads. If multiple CPUs try to acquire a lock simultaneously - LSE ensures one CPU
will indeed get the lock (with just one transaction), while LDRX/STRX could have multiple CPUS looping and
no-one acquiring a lock. This is why I believe just looking at "reasonable" benchmarks misses out on effects
real customers will run into.

Happy to see another arm-optimization thread so quickly :)

Thank you!
Tsahi.