Date: Sun, 18 Nov 2018 11:45:38 +0100 From: =?UTF-8?B?VMSzbA==?= Coosemans <tijl@FreeBSD.org> To: Matthew Macy <mat.macy@gmail.com> Cc: src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r339618 - head/sys/compat/linuxkpi/common/include/linux Message-ID: <20181118114538.546a4fab@kalimero.tijl.coosemans.org> In-Reply-To: <CAPrugNq3HXvPccFzRxFK79o2fK3KzCzpn7BzEim9MyXxGnJ%2Bpw@mail.gmail.com> References: <201810222055.w9MKtZPt013627@repo.freebsd.org> <CAPrugNoMVDyg-CnVh5NUgrxdaHcbo3CibC3RsPQ7FVtdJ=FJdQ@mail.gmail.com> <CAPrugNq3HXvPccFzRxFK79o2fK3KzCzpn7BzEim9MyXxGnJ%2Bpw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 17 Nov 2018 14:55:05 -0800 Matthew Macy <mat.macy@gmail.com> wrote: > When looking at powerpc io.h raw and relaxed are not aliases, but it > appears that on x86, they are: > https://github.com/torvalds/linux/blob/master/arch/x86/include/asm/io.h >=20 > Sorry for the noise. But let's starting moving the x86 specific > atomic.h and io.h under asm/x86. Yes, I agree that the file should be moved to an arch specific location. And the functions should probably be implemented using inline asm like they are on Linux in case there are differences in the way compilers treat the C code versus the asm code. > On Sat, Nov 17, 2018 at 2:01 PM Matthew Macy <mat.macy@gmail.com> wrote: >> You should probably revert this. The implied understanding of the >> _relaxed version is incorrect. compiler_membar is there to prevent >> instruction reordering which is possible on FreeBSD because the accesses >> are done in C. The relaxed variants still do not permit instruction >> reordering. On Linux __compiler_member (referred to as barrier there) >> isn=E2=80=99t necessary in the mmio accessors because they always use vo= latile >> asm which can=E2=80=99t be reordered. The distinction between the relaxe= d and >> non relaxed variants is that the relaxed variant lacks memory barriers >> (sync / lwsync / eieio on ppc, membar on sparc, etc). Quoting https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html: "Note that the compiler can move even volatile asm instructions relative to other code, including across jump instructions." So I think the Linux implementation of the relaxed variant lacks both CPU and compiler barriers. >> Most of the time we don=E2=80=99t run in to problems on x86 because with= TSO >> the only reordering possible is writes that happen before reads can >> become visible in memory after they occur in the instruction stream. Note that these functions are normally used on uncacheable memory which is strongly ordered on x86. There should be no reordering at all. On PowerPC barrier instructions are needed to prevent reordering.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20181118114538.546a4fab>