From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Henry <rrh(dot)henry(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: postgres has no spinlock support on riscv rv64imafdc |
Date: | 2021-04-15 08:54:37 |
Message-ID: | CA+hUKGKnXHpROE+m-Qw006V77Yo9NfTKAW2B-xn7XmDiRwmUZQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Fri, Dec 13, 2019 at 10:59 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> On 2019-10-20 00:23:07 -0400, Tom Lane wrote:
> > Andres Freund <andres(at)anarazel(dot)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)
From | Date | Subject | |
---|---|---|---|
Next Message | PG Bug reporting form | 2021-04-15 09:15:35 | BUG #16963: Wrong command in C:\Program Files (x86)\PostgreSQL\10\pg_env.bat |
Previous Message | Bruce Momjian | 2021-04-14 20:15:57 | Re: BUG #16962: Conflicting Request Error Installing pgAudit |