pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Alexander Lakhin <exclusion@gmail.com>
To: Thomas Munro <thomas.munro@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Cc: greg@burd.me
Subject: Re: IO in wrong state on riscv64
Date: Thu, 23 Oct 2025 10:00:00 +0300
Message-ID: <927941c8-e5a1-4787-bbd9-88f0d92b55d0@gmail.com> (raw)
In-Reply-To: <CA+hUKGLJHW7QjNGpfo+yKD6GzhdVnHxaSf0QJZp4VTu7jAt68A@mail.gmail.com>
References: <d79691be-22bd-457d-9d90-18033b78c40a@gmail.com>
	<CA+hUKG+X=FKYecrpZaWNkWJZkQQWu6v2LvcD4nof1UftF7nZ9A@mail.gmail.com>
	<60bbebf4-0a80-4e5f-83c0-311c85f6bd5c@gmail.com>
	<CA+hUKGKRZufVhDEc1NDUXXHpTd9Q8gmvqbU+2cOUJZnK_TYJGA@mail.gmail.com>
	<c4cf94c2-e61c-444b-814f-1df85e52a39f@gmail.com>
	<CA+hUKGLpP2T90M3eEPB95KfB4PtdfVnEUNH+aoRiXfSk-ODJkQ@mail.gmail.com>
	<f2378a85-c968-4ccf-acf3-bca6f5c50c87@gmail.com>
	<CA+hUKGKcdkNTkn9C2MT3zM3ZTVLZTZTiLKXkWVDYWh4w7MNACA@mail.gmail.com>
	<CA+hUKGJKqC2VSg8_MCB4_3air3Zhk8x8K99KxHtLuoFFdVFnvg@mail.gmail.com>
	<w3qc4gzqywinffeglpwyxbwocpsjvh3yqqy5d42zsqhciy3yr5@tb63f2ipdzrl>
	<CA+hUKGLJHW7QjNGpfo+yKD6GzhdVnHxaSf0QJZp4VTu7jAt68A@mail.gmail.com>

Hello Thomas,

23.10.2025 00:51, Thomas Munro wrote:
> On a more practical note, Alexander, does this work?
>
>   #if !defined(pg_read_barrier_impl) && defined(HAVE_GCC__ATOMIC_INT32_CAS)
>   /* acquire semantics include read barrier semantics */
> -#              define pg_read_barrier_impl()
> __atomic_thread_fence(__ATOMIC_ACQUIRE)
> +#              define pg_read_barrier_impl()           do {
> __atomic_signal_fence(__ATOMIC_ACQUIRE);
> __atomic_thread_fence(__ATOMIC_ACQUIRE); } while (0)
>   #endif
>
> Someone might want to write an arch-riscv.h that spits out the asm
> instead (should be just FENCE R, R and FENCE W, W as far as I can see,
> which might be slightly better than what acquire/release generate, on
> paper at least), but apparently this problem is wider than RISCV so we
> need a general solution anyway.

Thank you for working on this!

Unfortunately, this change doesn't lead to change in disassembly of
pgaio_io_wait(), produced with clang-19 -O1. That is, I'm getting the same
disassembly as the one I sent you before (error/pgaio_io_wait.asm).
I tried:
  #if !defined(pg_read_barrier_impl) && defined(HAVE_GCC__ATOMIC_INT32_CAS)
  /* acquire semantics include read barrier semantics */
-#              define pg_read_barrier_impl() __atomic_thread_fence(__ATOMIC_ACQUIRE)
+#              define pg_read_barrier_impl()           do { } while (0)
  #endif
to make sure that the change of pg_read_barrier_impl() affects
pgaio_io_wait() and really saw a difference in the disassembly.

I haven't run tests with the modified version yet, going to test later
just to be sure, but I suppose we want to see the binary code changed.

Best regards,
Alexander

view thread (22+ messages)  latest in thread

Message-ID: <927941c8-e5a1-4787-bbd9-88f0d92b55d0@gmail.com>
Permalink:  ../927941c8-e5a1-4787-bbd9-88f0d92b55d0@gmail.com/
Also on:    postgresql.org/message-id/927941c8-e5a1-4787-bbd9-88f0d92b55d0@gmail.com

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: exclusion@gmail.com, thomas.munro@gmail.com, andres@anarazel.de, greg@burd.me
  Subject: Re: IO in wrong state on riscv64
  In-Reply-To: <927941c8-e5a1-4787-bbd9-88f0d92b55d0@gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox