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 ^
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 ^