From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | 吴亚飞 <wuyf41619(at)hundsun(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: spinlock support on loongarch64 |
Date: | 2022-11-02 17:27:06 |
Message-ID: | 20221102172706.e7aqmsh2phbsur3p@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2022-11-02 11:37:35 -0400, Tom Lane wrote:
> =?gb2312?B?zuLRx7fJ?= <wuyf41619(at)hundsun(dot)com> writes:
> > add spinlock support on loongarch64.
>
> I wonder if we shouldn't just do that (ie, try to use
> __sync_lock_test_and_set) as a generic fallback on any unsupported
> architecture. We could get rid of the separate stanza for RISC-V
> that way. The main thing that an arch-specific stanza could bring
> is knowledge of the best data type width to use for a spinlock;
> but I don't see a big problem with defaulting to "int". We can
> always add arch-specific stanzas for any machines where that's
> shown to be a seriously poor choice.
Yes, please. It might not be perfect for all architectures, and it might not
be good for some very old architectures. But for anything new it'll be vastly
better than not having spinlocks at all.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2022-11-02 17:48:22 | Re: Glossary and initdb definition work for "superuser" and database/cluster |
Previous Message | Andres Freund | 2022-11-02 17:25:44 | Re: Prefetch the next tuple's memory during seqscans |