Messages in this thread |  | | | Date | Thu, 7 Jan 2010 10:12:14 -0500 | | From | Mathieu Desnoyers <> | | Subject | Re: [RFC PATCH] introduce sys_membarrier(): process-wide memory barrier |
| |
* Andi Kleen (andi@firstfloor.org) wrote: > 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.
Do we still have many out there that support SMP ? Even newer ARM now need memory barriers.
> > > + * 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?
I'll go for PeterZ scheme, which is based on cpu_vm_mask.
Thanks,
Mathieu
> > -Andi
-- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
|  |