From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
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 18:29:44 |
Message-ID: | 1836682.1667413784@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2022-11-02 11:37:35 -0400, Tom Lane wrote:
>> 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.
So about like this, then.
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
fall-back-to-__sync_lock_test_and_set-1.patch | text/x-diff | 2.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-11-02 18:55:04 | Re: spinlock support on loongarch64 |
Previous Message | Justin Pryzby | 2022-11-02 18:10:17 | Re: pg15 inherited stats expressions: cache lookup failed for statistics object |