From patchwork Mon Nov 9 12:27:25 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vineet Gupta X-Patchwork-Id: 541751 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 578DA1402B0 for ; Mon, 9 Nov 2015 23:27:57 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b=dgM3Ut96; dkim-atps=neutral Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1ZvlYA-0007Av-Uq; Mon, 09 Nov 2015 12:27:54 +0000 Received: from mail-pa0-x229.google.com ([2607:f8b0:400e:c03::229]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1ZvlY9-00079L-88 for linux-snps-arc@lists.infradead.org; Mon, 09 Nov 2015 12:27:54 +0000 Received: by pacdm15 with SMTP id dm15so174117360pac.3 for ; Mon, 09 Nov 2015 04:27:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=Tx5CRZHSGjOm6wRlE2xm7bYOoj+x6i8EoIbdej5CJIM=; b=dgM3Ut96e8mYjIwnsaV1zPxfHnuX/LSPfqPvzZ0n7GCZWXi8Weq9Rbuinm8oy3tQq/ iFYelEp40when0Wyj7g/3g51+6BbyJTWpq+tCUbqbQFiCwlUJTU70BgwjXHKvE8ofjXB 1UR5UPAVdH/Oe+06T0GQFwfMHR+FCOaPopA2JXxMuPJlcP7ghsusQKFuCp5k+oSPoTAX dIYn4YFi0CgDnwn4ZIz5ojX/kaXeRMTH36GOIS5/3W2iDwpqNPbTqtYd8zsMxwz0QCPc 3CTsNehft8fIfx3APTeGvXpCXDFU6s1GE+RtFGJaoFzwbb0QHzA5UF0Beo+qXbePvUEU bDwg== X-Received: by 10.68.195.129 with SMTP id ie1mr39424608pbc.100.1447072052083; Mon, 09 Nov 2015 04:27:32 -0800 (PST) Received: from [192.168.0.10] ([182.70.186.45]) by smtp.googlemail.com with ESMTPSA id yp5sm16205430pac.38.2015.11.09.04.27.27 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Nov 2015 04:27:30 -0800 (PST) Subject: Re: [PATCH v2 16/19] ARC: [plat-eznps] Use dedicated cpu_relax() To: Peter Zijlstra References: <1446297327-16298-1-git-send-email-noamc@ezchip.com> <1446893557-29748-17-git-send-email-noamc@ezchip.com> <20151109100503.GH17308@twins.programming.kicks-ass.net> <20151109104533.GT3604@twins.programming.kicks-ass.net> From: Vineet Gupta Organization: Synopsys Message-ID: <5640912D.3010504@synopsys.com> Date: Mon, 9 Nov 2015 17:57:25 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151109104533.GT3604@twins.programming.kicks-ass.net> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20151109_042753_339592_57E684BE X-CRM114-Status: GOOD ( 18.13 ) X-Spam-Score: -2.2 (--) X-Spam-Report: SpamAssassin version 3.4.0 on bombadil.infradead.org summary: Content analysis details: (-2.2 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [2607:f8b0:400e:c03:0:0:0:229 listed in] [list.dnswl.org] 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (vineetg76[at]gmail.com) 0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (vineetg76[at]gmail.com) -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different X-BeenThere: linux-snps-arc@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Linux on Synopsys ARC Processors List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "gilf@ezchip.com" , "talz@ezchip.com" , "linux-kernel@vger.kernel.org" , "cmetcalf@ezchip.com" , Noam Camus , "linux-snps-arc@lists.infradead.org" Sender: "linux-snps-arc" Errors-To: linux-snps-arc-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org On Monday 09 November 2015 04:15 PM, Peter Zijlstra wrote: > On Mon, Nov 09, 2015 at 10:22:27AM +0000, Vineet Gupta wrote: >> On Monday 09 November 2015 03:35 PM, Peter Zijlstra wrote: >>> On Sat, Nov 07, 2015 at 12:52:34PM +0200, Noam Camus wrote: >>>> diff --git a/arch/arc/include/asm/processor.h b/arch/arc/include/asm/processor.h >>>> index 7266ede..50f9bae 100644 >>>> --- a/arch/arc/include/asm/processor.h >>>> +++ b/arch/arc/include/asm/processor.h >>>> @@ -58,12 +58,21 @@ struct task_struct; >>>> * get optimised away by gcc >>>> */ >>>> #ifdef CONFIG_SMP >>>> +#ifndef CONFIG_EZNPS_MTM_EXT >>>> #define cpu_relax() __asm__ __volatile__ ("" : : : "memory") >>>> #else >>>> +#define cpu_relax() \ >>>> + __asm__ __volatile__ (".word %0" : : "i"(CTOP_INST_SCHD_RW) : "memory") >>>> +#endif >>>> +#else >>>> #define cpu_relax() do { } while (0) >>> I'm fairly sure this is incorrect. Even on UP we expect cpu_relax() to >>> be a compiler barrier. >> >> We discussed this a while back (why do https:/lkml.org/lkml//.... links work >> psuedo randomly) >> >> http://marc.info/?l=linux-kernel&m=140350765530113 > > Hurm.. you have a better memory than me ;-) > > So in general we assume cpu_relax() implies a barrier() and I think we > have loops like: > > while (!var) > cpu_relax(); > > where var isn't volatile (or casted using READ_ONCE etc). > > See for instance: kernel/time/timer.c:lock_timer_base() which has: > > for (;;) { > u32 tf = timer->flags; > > if (!(tf & TIMER_MIGRATING)) { > ... > } > > cpu_relax(); > } > > So while TIMER_MIGRATING is set, it will only ever do regular loads, > which GCC is permitted to lift out if cpu_relax() is not a barrier. I'll just bite the bullet and make it a compiler barrier and send Linus way in 4.4. Care to provide an Ack or some such. --------------------> From e29de8efa621b825891dcc744c84965b38f6b868 Mon Sep 17 00:00:00 2001 From: Vineet Gupta Date: Mon, 9 Nov 2015 17:48:34 +0530 Subject: [PATCH] ARC: cpu_relax() to be compiler barrier even for UP cpu_relax() on ARC has been barrier only for SMP (and no-op for UP). Per recent discussions, it is safer to make it a compiler barrier unconditionally. Link: http://lkml.kernel.org/r/53A7D3AA.9020100@synopsys.com Cc: Peter Zijlstra Signed-off-by: Vineet Gupta Acked-by: Peter Zijlstra (Intel) --- arch/arc/include/asm/processor.h | 4 ---- 1 file changed, 4 deletions(-) diff --git a/arch/arc/include/asm/processor.h b/arch/arc/include/asm/processor.h index 44545354e9e8..1d694c1ef6d6 100644 --- a/arch/arc/include/asm/processor.h +++ b/arch/arc/include/asm/processor.h @@ -57,11 +57,7 @@ struct task_struct; * A lot of busy-wait loops in SMP are based off of non-volatile data otherwise * get optimised away by gcc */ -#ifdef CONFIG_SMP #define cpu_relax() __asm__ __volatile__ ("" : : : "memory") -#else -#define cpu_relax() do { } while (0) -#endif #define cpu_relax_lowlatency() cpu_relax()