From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 48462 invoked by alias); 10 Nov 2016 16:41:53 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 48238 invoked by uid 89); 10 Nov 2016 16:41:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=straight, H*r:sk:mail-he, H*r:sk:EUR01-H, H*r:104.47.0 X-HELO: EUR01-HE1-obe.outbound.protection.outlook.com Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=cmetcalf@mellanox.com; Subject: Re: Remove sparcv8 support To: David Miller , References: <502720f6-3057-41f5-7832-4b219f5f729f@redhat.com> <20161107.113825.631166023186879199.davem@davemloft.net> <1478711295.7146.969.camel@localhost.localdomain> <20161109.121552.63825213147087515.davem@davemloft.net> CC: , , , , From: Chris Metcalf Message-ID: <06d4798f-cf0b-fb29-04e5-daf9faadf46c@mellanox.com> Date: Thu, 10 Nov 2016 16:41:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161109.121552.63825213147087515.davem@davemloft.net> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: BLUPR0201CA0036.namprd02.prod.outlook.com (10.163.116.46) To HE1PR0501MB2762.eurprd05.prod.outlook.com (10.172.125.16) X-Microsoft-Exchange-Diagnostics: 1;HE1PR0501MB2762;2:ruGIp3y+F1s2GahN3J5xsNESrpqQD1+G9p7b5K5Sw82gYcMD6s9I4X99B96AdY3I4fRRnBwyeBzVWGhpBF65tDgrcWT4KYtPACTSXu3w4TxLhP89pd0z2u4xwe52yCuHYVsHjBxTt/ByblhVYvluVUz2FJJTjjgsUlVS/htQkus=;3:LWz5Mn4arqWHcdNuS2sx3odv1Tv+7e+VAF6Ajam3AtLTeS1l4tauyHO1VNqOnODfwtd1bAc9RW0vr2WGaSCFYK7mDO6cpyY7lzLff1WiGQ/qIma/Zwrg7rY62h67KY+OdaP/hCw6pYYJcJ4kVCkkTI/pwAI3jb5reTJO84ytfow= X-MS-Office365-Filtering-Correlation-Id: a35fa33e-0805-4987-028f-08d40988717b X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:HE1PR0501MB2762; X-Microsoft-Exchange-Diagnostics: 1;HE1PR0501MB2762;25:SQtI9WmbhWx2dUnARZGZwjAem7tjL1GLSe3ZL9cpSmFyvhTyuUONFH/5+LBcvfo1uKmxIVM0HCPPOukBrhJvrKhXsSFsr7iFng9CC/Y5u4TK7oS72BmYGko0kRGKdETXDI5IYeJT4vy2VanLeCbk4aCTlXplhG6yg7ESu4igrK/jPOWjrXqmSGcVc0wZuoVbBf8HZMybr1XVcfMqWVrBz1sHQy9edZSJmWvLBb1azXa+wLEz2qXUzuELOLlhqIebv/iHKlUzqojJbylElrgYdbcHRqxlzrS4Q3Qnfg/OX8z93HkQim1B1YI21GNrqAh6cUTIByBSIRco+dOoycYAfz70rVUOhUnuSuvP/f1Gn4eQ5/81Zws+/Wv1zqVuyO5t35t8bRGpKfLl66nvZ190fUk923AU2kM2eA1QuLPFL75A2MtgbO7FoaU0xp/s0rnlEtM9jHyM0/cXdNjYd55mEDfqATDnCEKmw138O+9xghwlswORwpFk3OpGMbBDWENil0ZZUTS48RGmAku3cBMSmyJvXqZUOQmGH+G2xSJvEfxuZ9vuL9PcUxO0DAcXUu70FU1TH6DjqRimz5KJLDRjg2A2OWAsh9PmK7jL44DSp2+bx5M10u/u0NVZppkO1NzzR2gOC4rxNDskq7x08Lu9U6TqFvSxeOhh6w+d89bE4GUCoE7P8okZqLMRmS0rSDXHApzTBqgjv7CayhVM0jeQPjEQ5fNFLIXe42SSe4U6Gh3+uj6gif/yWxAAR+NCfWAGED1PrihuRvVCKo64C0TczUG/B4TZzz76XqXOpbfnD7WLbc6oDHBTJbnoRCcPlx+r X-Microsoft-Exchange-Diagnostics: 1;HE1PR0501MB2762;31:GqcqLT7l8lQDypF7VEo+Oiv6kpPOOCSUE11ip7+dnEyexq4LSs/38wBtTDSjdx/fW1O+ttkFi370wCjjCeQAXMIWW4fhIwzcggIfvmKcnyVON6FRg5AI2M/VnvQU5P3DkS+26dcIVi1ixojPUM777mmT9JTVnL3ypWG1+/BEsEmTxE+TLfcJXedY5Qyr5euHKErp1WP+UCDigV3lzf71f8JmufzJ+OhXm1Hx234qppteP49rgVshVatXiSGDp/399R0FllbA/6kvQr5lfcbYwQ==;20:wPx5w0Y106o3ld1e8t/6+v/oZNJPrBZb2kTwe4DSGvgOBYgI8MPyc0gRYy/Vu6vlXJ03cYqo4qkeTD6sO07nd7OXawUtff8O2jy/wtRrsZE3OO1OfAKEeTH91pQIn3c3Hs4c53k1nqjRihycfLI/ACfyQs3ct4HDd1PI2uvELDyZZw+MrzOgygyV/egqFRMX+vvXwj6+SzpOJExhr4OiOeYXh13OK7UBATyVdoXxyblztKho5DFQB1Vx/cnfteoQM7C0lTO2/KzhGt341vLV4RnKwIuoyPifYpLTrlPCTbcLPgje6xbzvKrcaFBm7lYeGjmKPavGTXDTCV/TFVGo2b3Q8HKAQx1fwYcl3I0+org1msdNyDbXhRH6jbAicJk1gIqaumoarVemqg0r17WQdxkjSOr4s1GJIG8mmq6dX7F0V0b7Lw/7/jTYsTnPWBOGpm238OAZmBudwbq2ByK0HuPiQGrSaZAG0TQIIA7V2YnXupAzQrXgN7e4EVRDFAEZ X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(171992500451332); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026);SRVR:HE1PR0501MB2762;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0501MB2762; X-Microsoft-Exchange-Diagnostics: 1;HE1PR0501MB2762;4:GkQ06axsDzMiVCQu3rYhvR04ynrBWgeEF8Jtx82aMiDChwfZiadF8tEYNwhRk1paebgYzOKKQIc3pwncc7cMqV1ztOs/pmjTuWS2b/s7kAUrIt03rgOlI87sc+pokd8zl6EPRjX5iWgdIZ+EvfNxJgjxCsgLya40UDlmi2HKmPBWhZfRIxiHARQiytw0jsWqvBwfUp3f6k9ARz7CmP6rNbz30ZvrFCQ/9GSN1HSG4zD2jF1xkur26BmvpZg2UMrxx5mjf0TVLaeF0/PqvoueSyf5GikMabY3kmlgEHTFBPTtm4ZkLa4Ih7zXeypXV6u0s2CxoL1BeRkkBy18JoM0UzCQzcZTfQrkpOsqgfMAm23gGlpkXtMydhwk8SGGmjNhMDS4vJ0UJRjUgKJeY2UR4uzDGLy6H0OB5ma4AWsU+bwECcwsIsmga1tpMsE7mjOMc6r/0YP3UF6Nl8x+K0P/zw== X-Forefront-PRVS: 01221E3973 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(4630300001)(6009001)(6049001)(7916002)(24454002)(199003)(377454003)(189002)(105586002)(2906002)(586003)(106356001)(81166006)(8676002)(229853002)(305945005)(4326007)(7846002)(230700001)(189998001)(101416001)(64126003)(83506001)(47776003)(65806001)(66066001)(65956001)(50986999)(76176999)(54356999)(31696002)(81156014)(77096005)(86362001)(6666003)(68736007)(31686004)(3846002)(93886004)(97736004)(6116002)(7736002)(33646002)(42186005)(65826007)(4001350100001)(92566002)(50466002)(5001770100001)(2950100002)(36756003)(7116003)(23746002)(5660300001)(18886065003);DIR:OUT;SFP:1101;SCL:1;SRVR:HE1PR0501MB2762;H:[10.15.7.187];FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; Received-SPF: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1;HE1PR0501MB2762;23:Ak97KGOYqOopNmwTWVy7BIuuuJXmfujmYMS?= =?Windows-1252?Q?tfiN7s0yYbjlso7Y9WG7GDLrDa5kjK8QJtlRnH8Jc8ASkdJx/rt/rLTG?= =?Windows-1252?Q?FVsQ0RGb8tox6OPaKxeP9uSJemqyrmFGahqWNpRwWOympPGUyEQ3ODWs?= =?Windows-1252?Q?bC1ML9z8N3jhIqtue9qjKN1TOs6tug29/8en6EN0NLH+Ouoq6Ivxm3q4?= =?Windows-1252?Q?Znaks/GYjsKu+qyA47bho32hhjSrTvVsFSUA94LP95enxAvINeHLhWEs?= =?Windows-1252?Q?DvBvZvlGDuhBaLRqHTGn25DFmyaJYXrG/kZw9923Mv9nA3urGZw75p6N?= =?Windows-1252?Q?1Qgc9ZACa6woPzClWnoVO1aPzYHZrSUjZu79UyPLHBuV0haN3CzzHHA6?= =?Windows-1252?Q?jMOFYm1h0KC9G+Ty6s8yrTMGZw1CvIuu3+cPxwcUvfAoIFgX646Cnh3p?= =?Windows-1252?Q?fKAxYarnS1+DxR9KV/Pr7z8VbM+f+SdQ1GE3DJwL4lN59JWXXmSV1RAM?= =?Windows-1252?Q?GtRbSE1Y+yehGU5RYDNZLE3d30C5sAWTEyQPCvOKlAOVEq9O3V28q0NW?= =?Windows-1252?Q?tjtbpjql+cU+2IN8Sfg4X4qnAiyxd5iarUfHNNB9VsdLiU3sSw3sR0Wl?= =?Windows-1252?Q?BSMuoc+n9elJhqOEEOLfiB5GYtJWv+jKMtb3u8913BDlu7/aWqkVNe1T?= =?Windows-1252?Q?6cXdR7Y1zI2d/uXkbCI07uMQsDBV4TIe0SNyUXbkL/haytscJ6Ce8zwG?= =?Windows-1252?Q?wxVYg4peSvXAThPGKg+Br/WwDa8zVQB4gbWhkY5iG1SjaJjS2g+0O7lm?= =?Windows-1252?Q?a8y/O9zFewjndyfHkIsV4rsvfxgazP03fc4r/aXTOjmemEBNz6snfhq0?= =?Windows-1252?Q?gSdWSafxPp3vimB+0JRWrt+0CXu08scKzkZYJR5SNz83+AJy1bZSbOHn?= =?Windows-1252?Q?Vz2mddm/ZTWDxAqfurz0goKapN+6diRvGcMRvft4uaLSgJLZuKjcqkks?= =?Windows-1252?Q?eYOGOmhBn31OvojwgWeeuX8ImtcI40FRzaBMRC54vGlR5HdmGGG7kpTj?= =?Windows-1252?Q?Wkfh7jc6NCHyOPVWcKwUWYE6C4x99m9zn1CG1ssP8sJH2KLy6GbafsNm?= =?Windows-1252?Q?O+OHgtZRw5KVmp5hFXWEcjll9Ax883uzE6hSZjRgafChDiXxozDDdX9w?= =?Windows-1252?Q?YswTWdEtGoNDcg7YZM9qZoISgUFQzKjDI42f+e6CM+5dQxK7Ec2Sk9WS?= =?Windows-1252?Q?zpBaSTMLq/qHgwz5vugsjMbXdjS1dTu2iaR0R3VV7GFRkg+YIz/BDx1F?= =?Windows-1252?Q?6/DNEAkwZZ2LMoWsj0vG/UwtGBJ1OFT7C4GeaQ8FTzzX/HpcPREqiWHn?= =?Windows-1252?Q?z98pDoQyerKuw8k3fMhf0SeXD9NmMCm9v9G0Z5jWKGMIkMuMnG82xgDR?= =?Windows-1252?Q?Xfp9ILTwd6vFWsoQRCZTmZUlnUy1TBGS+RWmWjZSLOA=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1;HE1PR0501MB2762;6:FgBe5fZ9cNQEE71R2jMgqNAFJcy/+1Kod0JqUFfk7nFQ96dW8hD5oNcnDZdNItu++e/ooZ4dvLGnBT1VqnCBfHG9Us7Tfeg7XbxzKVQn1cnR/7TVkvmtkqrbS2eqvfGAsOcmv83Puy50oo5Q10Njkr+zvVo7y3yFUYn65h5B88MQ4P2+L8dPXQLHMr+UOo4TlCUEqVOJHcdftnZ1Q8ryLGB52wVAgbiLMjOUAYbqo+FY2X2N49E69spEFbOBzpNxENDbtwnKpNjkNCtShn/2v8XsZEE2T8Pxiz9aQYiN6R9fs14xMd0VyXbDiMbr8a+EYnaaskJ1MX1mPJAS6r7iWoDcxbgounHHboBMVNTjWv4=;5:bLKKQqXbhNAasRh5ia+Hc/inKSwcRBm6h5Z0os+mTwKRbUd8u4zDa6QLKHEGmFBoi/OK6ndhdj9t+hhd6kVtAnTG1jINd8rr7LHO0a8aC+I5n4U8AH7gaqLY++p8ZpsR3pbBJSXPaOPCXIzUoXXpkw==;24:0Ci2WStc2vv5PJZO+nY9xbP9iKgwysEfsQdy+epv/QBvz4/r2e7kiMqKWxfQU0CmGbbiJsfn0JGM2Nb28LnIIKmglOKuPkhqaKLy4hf6R+U= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;HE1PR0501MB2762;7:vmKi8EZGXAnuadB8ptEha3P3UvnGEoyBnF3aMdxuG8Vro/Oy0q9sWEp/AknYa8r/621lZjoAtS0gDZirvxQ9g+EeaB9sdcl7G1ob3K+hqBxel2QzbKuSu29EgPANWrMVZB4YrKMTd/z0nSFHVW93ALjtY/HqRglMpgPGoZcLVAtFw+vAjhrOSNOPzwj14f2aSfGsXM8sLCBH+Zi4gAWMXxE9ZDD/Hz4+7TqJYg0Y8MYkUuvgIQh9M4+R44goEbgsRaUuJowVODKeZGFVlR68CWl+XatN2PnKEFdjeCPGIrdBQr9yJzT6yobaEImeoYoVmHKuRqQTYnvJxmM62c6OtuxlA0wL2U9T2ZEcSrA5SlA= X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Nov 2016 16:41:37.8041 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0501MB2762 X-SW-Source: 2016-11/txt/msg00401.txt.bz2 On 11/9/2016 12:15 PM, David Miller wrote: > From: Torvald Riegel > Date: Wed, 09 Nov 2016 09:08:15 -0800 > >> What approach are you going to use in the kernel to emulate the CAS if >> the hardware doesn't offer one? If you are not stopping all threads, >> then there could be concurrent stores to the same memory location >> targeted by the CAS; to make such stores atomic wrt. the CAS, you would >> need to implement atomic stores in glibc to also use the kernel (eg, to >> do a CAS). > I keep hearing about this case, but as long as the CAS is atomic what > is the difference between the store being synchronized in some way > or not? > > I think the ordering allowed for gives the same set of legal results. > > In any possible case either the CAS "wins" or the async store "wins" > and that determines the final result written. All combinations are > legal outcomes even with a hardware CAS implementation. That's not actually true. Suppose you have an initial zero value, and you race with a store of 2 and a kernel CAS from 0 to 1. The legal output is only 2: either the store hit first and the CAS failed, or the CAS hit first and succeeded, then was overwritten by the 2. But if the kernel CAS starts first and loads the zero, then the store hits and sets the value to 2, the CAS will still decide it was successful and write the 1, thus leaving the value illegally set to 1. > I really don't think such asynchronous stores are legal, nor should > the be explicitly accomodated in the CAS emulation support. Either > the value is maintained in an atomic manner, or it is not. And if it > is, updates must use CAS. Straight stores are only legal on the > initialization of the word before any CAS code paths can get to the > value. > > I cannot think of any sane setup that can allow async stores > intermixed with CAS updates. So despite arguing above that mixing CAS and asynchronous store is safe, here you are arguing that you shouldn't do it? In any case yes, I think you have come to the right conclusion, and you shouldn't do it. If you're interested, I have some optimized code for the tilepro architecture to handle this in arch/tile. In kernel/intvec_32.S, the intvec_\vecname macro does a fastpath check for negative syscalls and calls out to sys_cmpxchg, which does some optimized work to figure out how to provide optimized atomics. We actually support both 32 and 64-bit cmpxchg, as well as an "atomic_update" that does (*mem & mask) + added, giving obvious implementations for atomic_exchange, atomic_exchange_and_add, atomic_and_val, and atomic_or_val (see glibc's sysdeps/tile/tilepro/atomic-machine.h). There's some very hairy stuff designed to handle the case of faulting with a bad user address here, since we haven't set up the kernel stack yet. But it works, and it's quite fast (about 50 cycles to do the fast syscall). We also hook into the same logic to support a more extended set of in-kernel atomic operations; see arch/tile/lib/atomic*32* for that stuff. The underlying locking is done by hashing into a lock table based on the low bits of the address, which lets us support process-shared as well as process-private, although it does mean that if multiple processes start up roughly simultaneously and all try to lock the same process-private futex, they contend with each other since they're using the same VA. Oh well; we didn't come up with a better solution that had good uncontended performance, but perhaps there are better solutions to the hash function. -- Chris Metcalf, Mellanox Technologies http://www.mellanox.com