On 11 February 2014 11:34, Will Deacon <will.deacon@xxxxxxx> wrote: > On Tue, Feb 11, 2014 at 08:15:19AM +0000, Vincent Guittot wrote: >> On 10 February 2014 17:46, Mark Brown <broonie@xxxxxxxxxx> wrote: >> > On Mon, Feb 10, 2014 at 04:22:31PM +0000, Catalin Marinas wrote: >> >> On Mon, Feb 10, 2014 at 01:02:01PM +0000, Mark Brown wrote: >> > >> >> > + if (cpu != cpuid) >> >> > + cpumask_set_cpu(cpu, &cpuid_topo->thread_sibling); >> >> > + } >> >> > + smp_wmb(); >> > >> >> I now noticed there are a couple of smp_wmb() calls in this patch. What >> >> are they for? >> > >> > To be honest I mostly cargo culted them from the ARM implementation; I >> > did look a bit but didn't fully dig into it - it seemed they were >> > required to ensure that the updates for the new CPU are visible over all >> > CPUs. Vincent? >> >> Yes that's it. we must ensure that updates are made visible to other CPUs > > In relation to what? The smp_* barriers ensure ordering of observability > between a number of independent accesses, so you must be ensuring > ordering against something else. Also, you need to guarantee ordering on the > read-side too -- how is this achieved? I can't see any smp_rmb calls from a > quick grep, so I assume you're making use of address dependencies? The boot sequence ensures the rmb Vincent > > /confused > > Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/linux-arm-kernel