On Sun, 2026-09-27 at 19:59 -0700, Rick wrote: > On 9/27/2026 3:47 AM, Michael Tokarev wrote: > > From: wangyang <[email protected]> > > > > In linux-user parallel execution, AMO and ordinary integer stores > do not > > invalidate load reservations held by another hart. > [...] > > Use the existing EXCP_ATOMIC path to re-execute LR, SC, AMO, and > ordinary > > integer store instructions in a serial context. > [...] > > Please hold this patch out of 11.1.2. It makes riscv64 user-mode > emulation much slower, and multi-threaded guests can stall. > > Once a guest has a second thread (CF_PARALLEL), gen_store() exits > through EXCP_ATOMIC on every ordinary integer store, so each store > stops all other vCPUs (cpu_exec_step_atomic -> start_exclusive). > LR, SC and AMOs take the same path. In addition, every store, > single-threaded or not, calls helper_riscv_invalidate_reservations(), > which walks all CPUs. > > xz compressing 2 MB at -6, without and with the patch: > > without patch with patch > xz -T1 5 s 122 s (identical output) > xz -T8 1 s no output after 600 s > > Measured with bsd-user on a FreeBSD 15.1/amd64 host running a FreeBSD > riscv64 userland. The only difference between the two builds is > reverting 5089493e45. The code involved is target/riscv under > CONFIG_USER_ONLY, which linux-user shares, but I have not measured > linux-user yet. I found this today while investigating riscv64 hangs > in bsd-user. > > I'm not disputing the correctness fix for work item 4149 (a same- > value > store by another hart must break an LR reservation), only the cost of > serializing every store to get it. That issue was found by a > synthetic > test, while this regression hits ordinary multi-threaded programs, so > I'd suggest leaving the patch out of stable until master has a > cheaper > approach.
wangyang <[email protected]>, any thoughts here? The patch seems to stop all CPUs to check reservations on every single store. Which would have a very large performance overhead. That's way too much over head. I'm going to revert this patch until we have a better solution Alistair > > Rick Richard
