From: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> To: <linux-mips@linux-mips.org>, <benh@kernel.crashing.org>, <will.deacon@arm.com>, <linux-kernel@vger.kernel.org>, <ralf@linux-mips.org>, <markos.chandras@imgtec.com>, <macro@linux-mips.org>, <Steven.Hill@imgtec.com>, <alexander.h.duyck@redhat.com>, <davem@davemloft.net> Subject: [PATCH 0/3] MIPS: SMP memory barriers: lightweight sync, acquire-release Date: Mon, 1 Jun 2015 17:09:25 -0700 [thread overview] Message-ID: <20150602000818.6668.76632.stgit@ubuntu-yegoshin> (raw) The following series implements lightweight SYNC memory barriers for SMP Linux and a correct use of SYNCs around atomics, futexes, spinlocks etc LL-SC loops - the basic building blocks of any atomics in MIPS. Historically, a generic MIPS doesn't use memory barriers around LL-SC loops in atomics, spinlocks etc. However, Architecture documents never specify that LL-SC loop creates a memory barrier. Some non-generic MIPS vendors already feel the pain and enforces it. With introduction in a recent out-of-order superscalar MIPS processors an aggressive speculative memory read it is a problem now. The generic MIPS memory barrier instruction SYNC (aka SYNC 0) is something very heavvy because it was designed for propogating barrier down to memory. MIPS R2 introduced lightweight SYNC instructions which correspond to smp_*() set of SMP barriers. The description was very HW-specific and it was never used, however, it is much less trouble for processor pipelines and can be used in smp_mb()/smp_rmb()/smp_wmb() as is as in acquire/release barrier semantics. After prolonged discussions with HW team it became clear that lightweight SYNCs were designed specifically with smp_*() in mind but description is in timeline ordering space. So, the problem was spotted recently in engineering tests and it was confirmed with tests that without memory barrier load and store may pass LL/SC instructions in both directions, even in old MIPS R2 processors. Aggressive speculation in MIPS R6 and MIPS I5600 processors adds more fire to this issue. 3 patches introduces a configurable control for lightweight SYNCs around LL/SC loops and for MIPS32 R2 it was allowed to choose an enforcing SYNCs or not (keep as is) because some old MIPS32 R2 may be happy without that SYNCs. In MIPS R6 I chose to have SYNC around LL/SC mandatory because all of that processors have an agressive speculation and delayed write buffers. In that processors series it is still possible the use of SYNC 0 instead of lightweight SYNCs in configuration - just in case of some trouble in implementation in specific CPU. However, it is considered safe do not implement some or any lightweight SYNC in specific core because Architecture requires HW map of unimplemented SYNCs to SYNC 0. --- Leonid Yegoshin (3): MIPS: R6: Use lightweight SYNC instruction in smp_* memory barriers MIPS: enforce LL-SC loop enclosing with SYNC (ACQUIRE and RELEASE) MIPS: bugfix - replace smp_mb with release barrier function in unlocks arch/mips/Kconfig | 47 ++++++++++++++++++++++++++++++++++++++ arch/mips/include/asm/barrier.h | 32 +++++++++++++++++++++++--- arch/mips/include/asm/bitops.h | 2 +- arch/mips/include/asm/spinlock.h | 2 +- 4 files changed, 77 insertions(+), 6 deletions(-) -- Signature
WARNING: multiple messages have this Message-ID (diff)
From: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> To: linux-mips@linux-mips.org, benh@kernel.crashing.org, will.deacon@arm.com, linux-kernel@vger.kernel.org, ralf@linux-mips.org, markos.chandras@imgtec.com, macro@linux-mips.org, Steven.Hill@imgtec.com, alexander.h.duyck@redhat.com, davem@davemloft.net Subject: [PATCH 0/3] MIPS: SMP memory barriers: lightweight sync, acquire-release Date: Mon, 1 Jun 2015 17:09:25 -0700 [thread overview] Message-ID: <20150602000818.6668.76632.stgit@ubuntu-yegoshin> (raw) Message-ID: <20150602000925.lhID_gmStfKzNt_B7WHHyI232WjS1oB1MMZDLBxgjw4@z> (raw) The following series implements lightweight SYNC memory barriers for SMP Linux and a correct use of SYNCs around atomics, futexes, spinlocks etc LL-SC loops - the basic building blocks of any atomics in MIPS. Historically, a generic MIPS doesn't use memory barriers around LL-SC loops in atomics, spinlocks etc. However, Architecture documents never specify that LL-SC loop creates a memory barrier. Some non-generic MIPS vendors already feel the pain and enforces it. With introduction in a recent out-of-order superscalar MIPS processors an aggressive speculative memory read it is a problem now. The generic MIPS memory barrier instruction SYNC (aka SYNC 0) is something very heavvy because it was designed for propogating barrier down to memory. MIPS R2 introduced lightweight SYNC instructions which correspond to smp_*() set of SMP barriers. The description was very HW-specific and it was never used, however, it is much less trouble for processor pipelines and can be used in smp_mb()/smp_rmb()/smp_wmb() as is as in acquire/release barrier semantics. After prolonged discussions with HW team it became clear that lightweight SYNCs were designed specifically with smp_*() in mind but description is in timeline ordering space. So, the problem was spotted recently in engineering tests and it was confirmed with tests that without memory barrier load and store may pass LL/SC instructions in both directions, even in old MIPS R2 processors. Aggressive speculation in MIPS R6 and MIPS I5600 processors adds more fire to this issue. 3 patches introduces a configurable control for lightweight SYNCs around LL/SC loops and for MIPS32 R2 it was allowed to choose an enforcing SYNCs or not (keep as is) because some old MIPS32 R2 may be happy without that SYNCs. In MIPS R6 I chose to have SYNC around LL/SC mandatory because all of that processors have an agressive speculation and delayed write buffers. In that processors series it is still possible the use of SYNC 0 instead of lightweight SYNCs in configuration - just in case of some trouble in implementation in specific CPU. However, it is considered safe do not implement some or any lightweight SYNC in specific core because Architecture requires HW map of unimplemented SYNCs to SYNC 0. --- Leonid Yegoshin (3): MIPS: R6: Use lightweight SYNC instruction in smp_* memory barriers MIPS: enforce LL-SC loop enclosing with SYNC (ACQUIRE and RELEASE) MIPS: bugfix - replace smp_mb with release barrier function in unlocks arch/mips/Kconfig | 47 ++++++++++++++++++++++++++++++++++++++ arch/mips/include/asm/barrier.h | 32 +++++++++++++++++++++++--- arch/mips/include/asm/bitops.h | 2 +- arch/mips/include/asm/spinlock.h | 2 +- 4 files changed, 77 insertions(+), 6 deletions(-) -- Signature
next reply other threads:[~2015-06-02 0:09 UTC|newest] Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-06-02 0:09 Leonid Yegoshin [this message] 2015-06-02 0:09 ` [PATCH 0/3] MIPS: SMP memory barriers: lightweight sync, acquire-release Leonid Yegoshin 2015-06-02 0:09 ` [PATCH 1/3] MIPS: R6: Use lightweight SYNC instruction in smp_* memory barriers Leonid Yegoshin 2015-06-02 0:09 ` Leonid Yegoshin 2015-06-02 10:08 ` Paul Burton 2015-06-02 10:08 ` Paul Burton 2015-06-02 12:12 ` Luc Van Oostenryck 2015-06-02 12:44 ` Ralf Baechle 2015-06-02 18:20 ` Leonid Yegoshin 2015-06-02 18:20 ` Leonid Yegoshin 2015-06-02 10:48 ` James Hogan 2015-06-02 10:48 ` James Hogan 2015-06-02 16:15 ` Maciej W. Rozycki 2015-06-02 23:56 ` David Daney 2015-06-03 1:56 ` Leonid Yegoshin 2015-06-03 1:56 ` Leonid Yegoshin 2015-06-05 13:10 ` Ralf Baechle 2015-06-05 21:18 ` Maciej W. Rozycki 2016-01-28 2:28 ` Joshua Kinard 2016-01-29 13:32 ` Maciej W. Rozycki 2016-01-29 13:32 ` Maciej W. Rozycki 2016-01-30 16:25 ` Joshua Kinard 2015-06-02 0:09 ` [PATCH 2/3] MIPS: enforce LL-SC loop enclosing with SYNC (ACQUIRE and RELEASE) Leonid Yegoshin 2015-06-02 0:09 ` Leonid Yegoshin 2015-06-02 11:39 ` James Hogan 2015-06-02 11:39 ` James Hogan 2015-06-02 18:43 ` Leonid Yegoshin 2015-06-02 18:43 ` Leonid Yegoshin 2015-06-02 18:53 ` Leonid Yegoshin 2015-06-02 0:09 ` [PATCH 3/3] MIPS: bugfix - replace smp_mb with release barrier function in unlocks Leonid Yegoshin 2015-06-02 0:09 ` Leonid Yegoshin 2015-06-02 11:42 ` James Hogan 2015-06-02 11:42 ` James Hogan 2015-06-02 13:22 ` Ralf Baechle 2015-06-02 8:41 ` [PATCH 0/3] MIPS: SMP memory barriers: lightweight sync, acquire-release Joshua Kinard 2015-06-02 9:59 ` Ralf Baechle 2015-06-02 18:59 ` Joshua Kinard 2015-06-02 19:19 ` Ralf Baechle
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20150602000818.6668.76632.stgit@ubuntu-yegoshin \ --to=leonid.yegoshin@imgtec.com \ --cc=Steven.Hill@imgtec.com \ --cc=alexander.h.duyck@redhat.com \ --cc=benh@kernel.crashing.org \ --cc=davem@davemloft.net \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mips@linux-mips.org \ --cc=macro@linux-mips.org \ --cc=markos.chandras@imgtec.com \ --cc=ralf@linux-mips.org \ --cc=will.deacon@arm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.