From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754623AbbFSKJv (ORCPT ); Fri, 19 Jun 2015 06:09:51 -0400 Received: from smtprelay.synopsys.com ([198.182.60.111]:39917 "EHLO smtprelay.synopsys.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1751120AbbFSKJm (ORCPT ); Fri, 19 Jun 2015 06:09:42 -0400 Message-ID: <5583EA52.5080701@synopsys.com> Date: Fri, 19 Jun 2015 15:39:22 +0530 From: Vineet Gupta User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 Newsgroups: gmane.linux.kernel,gmane.linux.kernel.cross-arch To: Will Deacon , Carlos Basto CC: "Peter Zijlstra (Intel)" , lkml , "linux-arch@vger.kernel.org" , "arc-linux-dev@synopsys.com" Subject: Re: [PATCH v2 22/28] ARCv2: STAR 9000837815 workaround hardware exclusive transactions livelock References: <20150610110234.GH3644@twins.programming.kicks-ass.net> <1434707726-32624-1-git-send-email-vgupta@synopsys.com> <20150619095932.GC18017@arm.com> In-Reply-To: <20150619095932.GC18017@arm.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.12.197.3] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Friday 19 June 2015 03:29 PM, Will Deacon wrote: > On Fri, Jun 19, 2015 at 10:55:26AM +0100, Vineet Gupta wrote: >> > A quad core SMP build could get into hardware livelock with concurrent >> > LLOCK/SCOND. Workaround that by adding a PREFETCHW which is serialized by >> > SCU (System Coherency Unit). It brings the cache line in Exclusive state >> > and makes others invalidate their lines. This gives enough time for >> > winner to complete the LLOCK/SCOND, before others can get the line back. >> > >> > Cc: Peter Zijlstra (Intel) >> > Signed-off-by: Vineet Gupta >> > --- >> > arch/arc/include/asm/atomic.h | 14 ++++++++++++-- >> > 1 file changed, 12 insertions(+), 2 deletions(-) >> > >> > diff --git a/arch/arc/include/asm/atomic.h b/arch/arc/include/asm/atomic.h >> > index 20b7dc17979e..03484cb4d16d 100644 >> > --- a/arch/arc/include/asm/atomic.h >> > +++ b/arch/arc/include/asm/atomic.h >> > @@ -23,13 +23,21 @@ >> > >> > #define atomic_set(v, i) (((v)->counter) = (i)) >> > >> > +#ifdef CONFIG_ISA_ARCV2 >> > +#define PREFETCHW " prefetchw [%1] \n" >> > +#else >> > +#define PREFETCHW >> > +#endif >> > + >> > #define ATOMIC_OP(op, c_op, asm_op) \ >> > static inline void atomic_##op(int i, atomic_t *v) \ >> > { \ >> > unsigned int temp; \ >> > \ >> > __asm__ __volatile__( \ >> > - "1: llock %0, [%1] \n" \ >> > + "1: \n" \ >> > + PREFETCHW \ >> > + " llock %0, [%1] \n" \ >> > " " #asm_op " %0, %0, %2 \n" \ >> > " scond %0, [%1] \n" \ >> > " bnz 1b \n" \ > Curious, but are you *sure* the prefetch should be *inside* the loop? > On most ll/sc architectures, that's a livelock waiting to happen because > you ping-pong the cache-line around in exclusive state. Indeed, the prefetchw inside the loop seems dubious, but this is what broke the h/w livelock when we were playing with multibench last year and what i was told to do by h/w folks. Let me go check once again ! -Vineet