Re: IO in wrong state on riscv64
От | Thomas Munro |
---|---|
Тема | Re: IO in wrong state on riscv64 |
Дата | |
Msg-id | CA+hUKGLpP2T90M3eEPB95KfB4PtdfVnEUNH+aoRiXfSk-ODJkQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: IO in wrong state on riscv64 (Alexander Lakhin <exclusion@gmail.com>) |
Ответы |
Re: IO in wrong state on riscv64
|
Список | pgsql-hackers |
On Mon, Oct 13, 2025 at 5:00 PM Alexander Lakhin <exclusion@gmail.com> wrote: > 13.10.2025 01:44, Thomas Munro wrote: > > On Sun, Oct 12, 2025 at 6:00 PM Alexander Lakhin <exclusion@gmail.com> wrote: > >> Please find those attached (gdb "disass/m pgaio_io_update_state" misses > >> the start of the function (but it's still disassembled below), so I > >> decided to share the whole output). > > Could you please also disassemble pgaio_io_reclaim()? > > Sure, the output of disass/m pgaio_io_reclaim is attached. Thanks. All seems to have something plausible in the right places, but I know nothing about RISC-V... hmm, what happens if you replace pg_{read,write}_barrier() with pg_memory_barrier(), in those three functions? And if it happens to help, perhaps you could try to figure out which one(s) help? Not that it should be necessary but as a clue or to rule out this line of enquiry... I guess that should generate FENCE RW,RW, meaning wait for all preceding reads and writes to complete and don't let any following reads or writes begin, but that's just from googling...
В списке pgsql-hackers по дате отправления: