On Sun, Mar 15, 2015 at 03:24:19PM -0400, Mathieu Desnoyers wrote: > Here is an implementation of a new system call, sys_membarrier(), which > executes a memory barrier on either all running threads of the current > process (MEMBARRIER_PRIVATE_FLAG) or calls synchronize_sched() to issue > a memory barrier on all threads running on the system. It can be used to > distribute the cost of user-space memory barriers asymmetrically by > transforming pairs of memory barriers into pairs consisting of > sys_membarrier() and a compiler barrier. For synchronization primitives > that distinguish between read-side and write-side (e.g. userspace RCU, > rwlocks), the read-side can be accelerated significantly by moving the > bulk of the memory barrier overhead to the write-side.
>From a quick review, this seems quite reasonable (as it did 5 years ago). One request: Could you please add a config option (default y) in the EXPERT menu to disable this? You actually seem to already have it marked as a cond_syscall. Also, a very minor nit: flags in kernel APIs aren't typically named with a _FLAG suffix. With the syscall made optional, and with or without that naming nit fixed: Reviewed-by: Josh Triplett <j...@joshtriplett.org> - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/