Messages in this thread | | | Date | Thu, 7 Jan 2010 19:30:10 +0100 | From | Oleg Nesterov <> | Subject | Re: [RFC PATCH] introduce sys_membarrier(): process-wide memory barrier |
| |
On 01/07, Peter Zijlstra wrote: > > On Wed, 2010-01-06 at 23:40 -0500, Mathieu Desnoyers wrote: > > http://marc.info/?t=126283939400002 > > > Index: linux-2.6-lttng/kernel/sched.c > > =================================================================== > > --- linux-2.6-lttng.orig/kernel/sched.c 2010-01-06 22:11:32.000000000 -0500 > > +++ linux-2.6-lttng/kernel/sched.c 2010-01-06 23:20:42.000000000 -0500 > > @@ -10822,6 +10822,36 @@ struct cgroup_subsys cpuacct_subsys = { > > }; > > #endif /* CONFIG_CGROUP_CPUACCT */ > > > > +/* > > + * Execute a memory barrier on all CPUs on SMP systems. > > + * Do not rely on implicit barriers in smp_call_function(), just in case they > > + * are ever relaxed in the future. > > + */ > > +static void membarrier_ipi(void *unused) > > +{ > > + smp_mb(); > > +} > > + > > Also, there was some talk a while ago about IPIs implying memory > barriers. Which I of course forgot all details about,.. at least sending > one implies a wmb and receiving one an rmb, but it could be stronger, > Oleg?
IIRC, it was decided that IPIs must imply mb(), but I am not sure this is true on any arch/
However, even if IPI didn't imply mb(), I don't understand why it is needed... After the quick reading of the original changelog in http://marc.info/?l=linux-kernel&m=126283923115068
Thread A Thread B prev mem accesses prev mem accesses sys_membarrier() barrier() follow mem accesses follow mem accesses
sys_membarrier() should "insert" mb() on behalf of B "instead" of barrier(), right? But, if we send IPI, B enters kernel mode and returns to user-mode. Should this imply mb() in any case?
Oleg.
| |