Обсуждение: [PATCH] Add loongarch64 native spin lock.

Поиск
Список
Период
Сортировка

[PATCH] Add loongarch64 native spin lock.

От
YANG Xudong
Дата:
Hi,

This patch set tries to add loongarch64 native spin lock to postgresql.

- [PATCH 1/2] implements a loongarch64 native spin lock.
- [PATCH 2/2] fixes s_lock_test to make it runnable via `make check'.

The patch set is tested on my Loongson 3A5000 machine with Loong Arch 
Linux and GCC 13.1.0 with default ./configure with no options.

Output of `make check' in src/backend/storage/lmgr is attached.

See:
[1]: 
https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html#atomic-memory-access-instructions
[2]: 

https://github.com/torvalds/linux/blob/f1fcbaa18b28dec10281551dfe6ed3a3ed80e3d6/arch/loongarch/include/asm/cmpxchg.h#L12

----
YANG Xudong
Вложения

Re: [PATCH] Add loongarch64 native spin lock.

От
Tom Lane
Дата:
YANG Xudong <yangxudong@ymatrix.cn> writes:
> This patch set tries to add loongarch64 native spin lock to postgresql.

This came up before, and our response was

https://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=1c72d82c2

In principle, at least, there is no longer any need for
machine-specific s_lock.h additions.  Is there a strong reason
why the __sync_lock_test_and_set solution isn't good enough?

            regards, tom lane



Re: [PATCH] Add loongarch64 native spin lock.

От
YANG Xudong
Дата:
Thanks for the information.

I checked the assembly code of __sync_lock_test_and_set generated by GCC 
for loongarch64. It is exactly the same as this patch.

I guess this patch is not necessary any more.

Regards

On 2023/5/17 20:37, Tom Lane wrote:
> YANG Xudong <yangxudong@ymatrix.cn> writes:
>> This patch set tries to add loongarch64 native spin lock to postgresql.
> 
> This came up before, and our response was
> 
> https://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=1c72d82c2
> 
> In principle, at least, there is no longer any need for
> machine-specific s_lock.h additions.  Is there a strong reason
> why the __sync_lock_test_and_set solution isn't good enough?
> 
>             regards, tom lane