Alexander Korotkov <aekorot...@gmail.com> writes: > On Tue, Dec 1, 2020 at 6:19 PM Krunal Bauskar <krunalbaus...@gmail.com> wrote: >> I would request you guys to re-think it from this perspective to help ensure >> that PGSQL can scale well on ARM. >> s_lock becomes a top-most function and LSE is not a universal solution but >> CAS surely helps ease the main bottleneck.
> CAS patch isn't proven to be a universal solution as well. We have > tested the patch on just a few processors, and Tom has seen the > regression [1]. The benchmark used by Tom was artificial, but the > results may be relevant for some real-life workload. Yeah. I think that the main conclusion from what we've seen here is that on smaller machines like M1, a standard pgbench benchmark just isn't capable of driving PG into serious spinlock contention. (That reflects very well on the work various people have done over the years to get rid of spinlock contention, because ten or so years ago it was a huge problem on this size of machine. But evidently, not any more.) Per the results others have posted, nowadays you need dozens of cores and hundreds of client threads to measure any such issue with pgbench. So that is why I experimented with a special test that does nothing except pound on one spinlock. Sure it's artificial, but if you want to see the effects of different spinlock implementations then it's just too hard to get any results with pgbench's regular scripts. And that's why it disturbs me that the CAS-spinlock patch showed up worse in that environment. The fact that it's not visible in the regular pgbench test just means that the effect is too small to measure in that test. But in a test where we *can* measure an effect, it's not looking good. It would be interesting to see some results from the same test I did on other processors. I suspect the results would look a lot different from mine ... but we won't know unless someone does it. Or, if someone wants to propose some other test case, let's have a look. > I'm expressing just my personal opinion, other committers can have > different opinions. I don't particularly think this topic is > necessarily a non-starter. But I do think that given ambiguity we've > observed in the benchmark, much more research is needed to push this > topic forward. Yeah. I'm not here to say "do nothing". But I think we need results from more machines and more test cases to convince ourselves whether there's a consistent, worthwhile win from any specific patch. regards, tom lane