Will Deacon <will.dea...@arm.com> wrote: > > Hi John, > > On Tue, Mar 11, 2014 at 02:54:18AM +0000, John Carr wrote: > > A comment in arm/sync.md notes "We should consider issuing a inner > > shareability zone barrier here instead." Here is my first attempt > > at a patch to emit weaker memory barriers. Three instructions seem > > to be relevant for user mode code on my Cortex A9 Linux box: > > > > dmb ishst, dmb ish, dmb sy > > > > I believe these correspond to a release barrier, a full barrier > > with respect to other CPUs, and a full barrier that also orders > > relative to I/O. > > Not quite; DMB ISHST only orders writes with other writes, so loads can move > across it in both directions. That means it's not sufficient for releasing a > lock, for example.
Release in this context doesn't mean "lock release". I understand it to mean release in the specific context of the C++11 memory model. (Similarly, if you're arguing standards compliance "inline" really means "relax the one definition rule for this function.") I don't see a prohibition on moving non-atomic loads across a release store. Can you point to an analysis that shows a full barrier is needed? If we assume that gcc is used to generate code for processes running within a single inner shareable domain, then we can start by demoting "dmb sy" to "dmb ish" for the memory barrier with no other change. If a store-store barrier has no place in the gcc atomic memory model, that supports my hypothesis that a twisty maze of ifdefs is superior to a "portable" attractive nuisance. > > <shameless plug> > > I gave a presentation at ELCE about the various ARMv7 barrier options (from > a kernel perspective): > > https://www.youtube.com/watch?v=6ORn6_35kKo > > </shameless plug> Conveniently just about the same length as a dryer cycle. I learned that inner shareable domain is the right one to use for normal user mode code, and the Linux kernel doesn't care because it has its own memory model and barrier functions.
