Messages in this thread | | | Subject | Re: [RFC PATCH] introduce sys_membarrier(): process-wide memory barrier | From | Andi Kleen <> | Date | Thu, 07 Jan 2010 10:50:26 +0100 |
| |
Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> writes:
> Both the signal-based and the sys_membarrier userspace RCU schemes > permit us to remove the memory barrier from the userspace RCU > rcu_read_lock() and rcu_read_unlock() primitives, thus significantly > accelerating them. These memory barriers are replaced by compiler > barriers on the read-side, and all matching memory barriers on the > write-side are turned into an invokation of a memory barrier on all > active threads in the process. By letting the kernel perform this > synchronization rather than dumbly sending a signal to every process > threads (as we currently do), we diminish the number of unnecessary wake > ups and only issue the memory barriers on active threads. Non-running > threads do not need to execute such barrier anyway, because these are > implied by the scheduler context switches.
I'm not sure all this effort is really needed on architectures with strong memory ordering.
> + * The current implementation simply executes a memory barrier in an IPI handler > + * on each active cpu. Going through the hassle of taking run queue locks and > + * checking if the thread running on each online CPU belongs to the current > + * thread seems more heavyweight than the cost of the IPI itself. > + */ > +SYSCALL_DEFINE0(membarrier) > +{ > + on_each_cpu(membarrier_ipi, NULL, 1);
Can't you use mm->cpu_vm_mask?
-Andi
| |