Date: Thu, 9 Apr 2015 08:14:49 +0200 From: Mateusz Guzik <mjguzik@gmail.com> To: freebsd-arch@freebsd.org Cc: Attilio Rao <attilio@FreeBSD.org>, adrian@freebsd.org, Konstantin Belousov <kib@FreeBSD.org>, Alan Cox <alc@rice.edu> Subject: Re: atomic ops Message-ID: <20150409061448.GB6086@dft-labs.eu> In-Reply-To: <20141028025222.GA19223@dft-labs.eu> References: <20141028025222.GA19223@dft-labs.eu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Oct 28, 2014 at 03:52:22AM +0100, Mateusz Guzik wrote: [scratching old content so that I hopefully re-state it nicer] I would like to reviwe the discussion about memory barriers provided in the kernel. The kernel (at least on amd64) lacks lightweight barriers providing only following guarantees: - all writes are completed prior to given point - all reads are completed prior to given point On amd64 such barriers require only compiler barrier, and as such obviously beat currently used operations like load_acq (which uses cmpxchg). Example consumer which would benefit greatly from such barriers is seq.h: https://svnweb.freebsd.org/base/head/sys/sys/seq.h?view=markup _load_acq on amd64 provides full barrier and it was noted we should not change that in order to not break possible 3rd party consumers. Also I don't see any alternative naming convention trying to stick to this scheme that we could use. As such I propose stealing naming from Linux and introduction of smp_wmb and smp_rmb macros providing aforementioned funcionality. So for amd64 this would be: #define smp_wmb() __compiler_membar() #define smp_rmb() __compiler_membar() Any objections? I'm happy to talk to arch maintainers in order to get relevant implementations for all architectures. -- Mateusz Guzik <mjguzik gmail.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150409061448.GB6086>