Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754378AbbFBAJk (ORCPT ); Mon, 1 Jun 2015 20:09:40 -0400 Received: from mailapp01.imgtec.com ([195.59.15.196]:62669 "EHLO mailapp01.imgtec.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751668AbbFBAJb (ORCPT ); Mon, 1 Jun 2015 20:09:31 -0400 Subject: [PATCH 0/3] MIPS: SMP memory barriers: lightweight sync, acquire-release From: Leonid Yegoshin To: , , , , , , , , , Date: Mon, 1 Jun 2015 17:09:25 -0700 Message-ID: <20150602000818.6668.76632.stgit@ubuntu-yegoshin> User-Agent: StGit/0.17.1-dirty MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.20.3.79] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3053 Lines: 58 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/