From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030757AbbD1Q7N (ORCPT ); Tue, 28 Apr 2015 12:59:13 -0400 Received: from mail-am1on0058.outbound.protection.outlook.com ([157.56.112.58]:54048 "EHLO emea01-am1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1030298AbbD1Q7J (ORCPT ); Tue, 28 Apr 2015 12:59:09 -0400 Authentication-Results: redhat.com; dkim=none (message not signed) header.d=none; Message-ID: <553FBC4F.3070104@ezchip.com> Date: Tue, 28 Apr 2015 12:58:55 -0400 From: Chris Metcalf User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Peter Zijlstra CC: "Paul E. McKenney" , Manfred Spraul , Oleg Nesterov , Kirill Tkhai , , Ingo Molnar , Josh Poimboeuf Subject: Re: [PATCH 2/2] [PATCH] sched: Add smp_rmb() in task rq locking cycles References: <20150218155904.GA27687@redhat.com> <54E4E479.4050003@colorfullife.com> <20150218224317.GC5029@twins.programming.kicks-ass.net> <20150219141905.GA11018@redhat.com> <54E77CC0.5030401@colorfullife.com> <20150220184551.GQ2896@worktop.programming.kicks-ass.net> <20150425195602.GA26676@linux.vnet.ibm.com> <20150426105213.GA27191@linux.vnet.ibm.com> <20150428143357.GF23123@twins.programming.kicks-ass.net> <553FACF1.2020405@ezchip.com> <20150428164033.GJ5029@twins.programming.kicks-ass.net> In-Reply-To: <20150428164033.GJ5029@twins.programming.kicks-ass.net> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [12.216.194.146] X-ClientProxiedBy: BLUPR07CA0039.namprd07.prod.outlook.com (10.255.223.152) To VI1PR02MB0783.eurprd02.prod.outlook.com (25.162.14.145) X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR02MB0783; X-Forefront-Antispam-Report: BMV:1;SFV:NSPM;SFS:(10009020)(6049001)(6009001)(479174004)(377454003)(24454002)(51704005)(2950100001)(87976001)(64126003)(122386002)(46102003)(4001350100001)(66066001)(42186005)(93886004)(110136001)(47776003)(50466002)(15975445007)(77096005)(23746002)(62966003)(77156002)(36756003)(54356999)(87266999)(50986999)(59896002)(86362001)(76176999)(83506001)(33656002)(65816999)(92566002)(65806001)(65956001)(19580395003)(40100003)(18886065003);DIR:OUT;SFP:1101;SCL:1;SRVR:VI1PR02MB0783;H:[10.7.0.41];FPR:;SPF:None;MLV:sfv;LANG:en; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(5002010)(5005006)(3002001);SRVR:VI1PR02MB0783;BCL:0;PCL:0;RULEID:;SRVR:VI1PR02MB0783; X-Forefront-PRVS: 0560A2214D X-OriginatorOrg: ezchip.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Apr 2015 16:59:04.2850 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR02MB0783 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/28/2015 12:40 PM, Peter Zijlstra wrote: > On Tue, Apr 28, 2015 at 11:53:21AM -0400, Chris Metcalf wrote: > >> The reason we use two 32-bit fields on tilepro is that the only available >> atomic instruction is tns (test and set), which sets a 32-bit "1" value >> into the target memory and returns the old 32-bit value. > And you want a ticket lock as opposed to the test-and-set lock because > with 64 tiles starvation under contention is a real worry? We see substantial unfairness under load with a plain spinlock, basically because nearer cores on the mesh network can exponentially crowd out further cores. The ticket lock avoids that, though we have to be careful to do backoff when checking the lock to avoid DDoS in the mesh network. > Where sparc32 (which only has the load-store-unsigned-byte instruction, > which is similar to your tns except it writes 0xff) has the benefit of > not actually having many CPUs you get to do 64 cpus! Yes, the 64-core thing is awesome, but the atomic instructions we built into the first generation chip weren't really adequate to the task. -- Chris Metcalf, EZChip Semiconductor http://www.ezchip.com