Re: spinlock support on loongarch64

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

In response to

Responses

Browse pgsql-hackers by date

  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