Sorry to jump in, I wrote the membarrier syscall LTP interface test (https://github.com/linux-test- project/ltp/blob/master/testcases/kernel/syscalls/membarrier/membarrier01.c) when I was at Linaro and felt attracted to reading all this during my bug triage day =).
So, for MEMBARRIER_CMD_PRIVATE_EXPEDITED, you said at the description: " It only targets threads which share the same mm as the thread calling the membarrier syscall " And it occurred to me right away: "Are there any dependencies using liburcu and Shared Mem IPC" ? Mainly because the private expedited only guarantees the barrier - for the RCU graceful period - among sibling tasks sharing the same address space and thread id (which share the same mm) -> of course this explains why it is much faster, specially in an OS containing tons of running tasks.. or even worse: in a VM with tons of running tasks PLUS vcpus coming in and out the real ones. So, I think my message here, specially for the SRU team, as this is changing the behavior of librcu library for a LTS version, is: - apart from feedback given by @mruffell, to also check if any of librcu consumers are depending on a full membarrier - driven by kernel - for ** shared pages among different processes ** before accepting this as a SRU. Or else we're changing synchronization primitives of all dependencies and this would not be good =o). I think this criteria may also help in the SRU acceptance ^ -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1876230 Title: liburcu: Enable MEMBARRIER_CMD_PRIVATE_EXPEDITED to address performance problems with MEMBARRIER_CMD_SHARED To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/liburcu/+bug/1876230/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
