Re: postgres has no spinlock support on riscv rv64imafdc
От | Thomas Munro |
---|---|
Тема | Re: postgres has no spinlock support on riscv rv64imafdc |
Дата | |
Msg-id | CA+hUKGKnXHpROE+m-Qw006V77Yo9NfTKAW2B-xn7XmDiRwmUZQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: postgres has no spinlock support on riscv rv64imafdc (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: postgres has no spinlock support on riscv rv64imafdc
|
Список | pgsql-bugs |
On Fri, Dec 13, 2019 at 10:59 AM Andres Freund <andres@anarazel.de> wrote: > On 2019-10-20 00:23:07 -0400, Tom Lane wrote: > > Andres Freund <andres@anarazel.de> writes: > > > On 2019-10-18 09:00:23 +0200, Tom Lane wrote: > > >> TBH, though, my preference would be for some assembly code rather than > > >> relying on GCC builtins as Richard's patch did. > > > > > -1. I think there's good arguments for using inline assembly on > > > platforms where we've done so historically, and where we have to support > > > old compilers without good support for intrinsics/builtins. But I see > > > very little reason for adding more such cases for newer platforms - > > > doing so correctly and efficiently is substantial work and fragile. > > > > The reason I'm skeptical of that line of argument is that gcc's track > > record for support of these intrinsics on non-mainstream architectures > > is just sucky. Now maybe, somebody was careful and it all works great > > on RISC-V. But IMO, the burden of proof is to show that the intrinsics > > work, not to show that they don't. > > I agree there've been problems. But I don't think one can make a lot of > conclusions from the intrinsics quality for dying platforms when judging > new platforms. Most if not all new platforms with a gcc port that PG > would be run on are going to be multi-core platforms - if intrinsics are > broken, there'll be more problems. Furthermore, we're fully exposed to > the intrinsics quality due to atomics anyway - a lot more even, because > there's a shrinking amount of contended spinlocks, and a lot more > contended lwlocks etc (which use atomics). And lastly, our spinlock > implementations have been far from perfect too. As a data point: the obvious change builds and passes basic testing with flying colours, on FreeBSD + clang 11 running under qemu. RISC-V has been "non-experimental" since clang 9. FWIW I've signed up to the preorder list to try to get my hands on some BeagleV hardware to test this stuff for real ASAP... -#if defined(__arm__) || defined(__arm) || defined(__aarch64__) || defined(__aarch64) +#if defined(__arm__) || defined(__arm) || defined(__aarch64__) || defined(__aarch64) || defined(__riscv)
В списке pgsql-bugs по дате отправления: