From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755185AbbKXVst (ORCPT ); Tue, 24 Nov 2015 16:48:49 -0500 Received: from mail-am1on0085.outbound.protection.outlook.com ([157.56.112.85]:23707 "EHLO emea01-am1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754438AbbKXVsq (ORCPT ); Tue, 24 Nov 2015 16:48:46 -0500 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=cmetcalf@ezchip.com; Subject: Re: [PATCH 1/7] atomic: Export fetch_or() To: Frederic Weisbecker References: <1447424529-13671-1-git-send-email-fweisbec@gmail.com> <1447424529-13671-2-git-send-email-fweisbec@gmail.com> <56548908.50509@ezchip.com> <20151124211951.GA16609@lerouge> CC: LKML , Peter Zijlstra , Thomas Gleixner , Luiz Capitulino , Christoph Lameter , Ingo Molnar , Viresh Kumar , Rik van Riel From: Chris Metcalf Message-ID: <5654DB33.1080706@ezchip.com> Date: Tue, 24 Nov 2015 16:48:35 -0500 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151124211951.GA16609@lerouge> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [12.216.194.146] X-ClientProxiedBy: BLUPR07CA0031.namprd07.prod.outlook.com (10.255.223.144) To AM3PR02MB116.eurprd02.prod.outlook.com (10.242.243.147) X-Microsoft-Exchange-Diagnostics: 1;AM3PR02MB116;2:tJfXIq3X5TYpJ1Ab5/XX6t+knftu0jL3xThFg4JnKiXiEz3lM7ns2DUH4mzYCcvklXGvU9BtbGwrUmClSpifxGfn7HcSENbT7CGXxew9E/pK9EM4/pUsnqxJrVYLhvLuSFMiZ9VUO1XF5n7q7ujuKg==;3:hhqgyB7ng7SN+jCOoOT+fWUFMzfJpqjk8SQV51aSZ6CD6txppa2V17DyxIgl+/C+RH4lcwkM5d0G2fYfgiR80m8a3qjnGV0oL82kgZyiP/IAnoItCdAFW08N5pJjGHXo;25:wpZjs7Bu9gs5cmDIEsWO21WMtPytRXaAhEE4/qheuwWFNMvV6jRuA9JvyxqOGENidNKIuWoDZhZDogYLP3qTwQuCAKrIWRsClDjD4a6hWhJJzu+Vk8kmNow1NIoOcAHH7y9pW2/DMo7AHN/Eeew+om6jtUPQ9TpfVtRyPUdaBW3sQ7BJsulZJpCi1hFQbCoQP4Ar690C5824TYpPDNV/Oaqb5edugNGvbQ2O2UdetF2uAShQI8AdUJ82HY1J+zkHEmFEYX+OwQvTmbhY2Ppz0A==;20:5Gf81/6tvOtebyKZXtHoXdWKAK5ZwTqOuuuTTT97Z/KmjKZ6t1OjCYKfifW3tU4YYNKOPOVz9SviSE5Zl1ch1B34+bjYg6TlgQ0MHJ6yDUvGcobSbP39SfLRQ2d7erz7dq3svZ38cm6AZSlPBUcNKH5LY/AhQfuwGv2CarUmBxk= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM3PR02MB116; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(121898900299872); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(3002001)(10201501046);SRVR:AM3PR02MB116;BCL:0;PCL:0;RULEID:;SRVR:AM3PR02MB116; X-Microsoft-Exchange-Diagnostics: 1;AM3PR02MB116;4:BZb0Yp4gfesEOVdV9WKDMB/MSZaD4SoEFHxaSPBj0vl+hIlaTh7tfjpDND8hUyeaTeNMXfgt6Njawius9BHoflTUnQgdDNnk3ILx50VfaC+7LUlFgTh6EC506tTRgeFvrYjdNyJu9XKfdnVa+E7KzwMF/AV6f3dL25/ONx4e9BMoE33tqBm+YC0CVmZu8gH0pYh+HNL+igiTg38EBtHpi4ojjpgahQfjDtEZEEPJKfsCu8RhHhgRFULqPILfDOC8CdLnz5guR58neFuRJXl+DfGt9HkKIBtSw+zd98tYezvlfVdadyMalTz39mC+5wr9W2qgxVUWwE07WKWVE8MuCi6EXjrT1tCJgT8MV60TjIu/WIQP5o/8l/FT2wpACZKh2rUZJloyd+l5frwSjsEaUR+hLKEGTk5gKwPTyvb5FGFGiv2See7tjjaHZUnaYCG5 X-Forefront-PRVS: 0770F75EA9 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(6049001)(6009001)(24454002)(189002)(479174004)(199003)(377454003)(23746002)(189998001)(87266999)(50986999)(80316001)(586003)(5004730100002)(65956001)(4001350100001)(65816999)(81156007)(40100003)(50466002)(5007970100001)(6116002)(76176999)(3846002)(110136002)(122386002)(101416001)(92566002)(54356999)(64126003)(36756003)(97736004)(19580395003)(47776003)(5001960100002)(59896002)(93886004)(5008740100001)(66066001)(105586002)(15975445007)(83506001)(106356001)(33656002)(5001920100001)(65806001)(77096005)(86362001)(230700001)(87976001)(2950100001)(42186005)(1411001)(21314002)(18886065003);DIR:OUT;SFP:1101;SCL:1;SRVR:AM3PR02MB116;H:[10.7.0.41];FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1;AM3PR02MB116;23:UNW7W+Y01cEEXgJmqBmZL1/jBPblGOv5Ez7hWb?= =?Windows-1252?Q?LNcIUnCYqGtx1R6Ux7CS7ojvBuNEWPx2vmZI52SUYEEx1TMgi222S7Gg?= =?Windows-1252?Q?vhDuXJEUA9/F1/j+tuau++0dR9FQTUTjzYuNu1YMi5S66dYLhtI8PyzX?= =?Windows-1252?Q?ZwMsMb9Glm93lhl3nDh5u9XvRgOKeP1acS4WpHGiRjyFkipDyDjcdC1O?= =?Windows-1252?Q?ldCKyrZNph63V8Q8p4EeEEHa6RPE/qFJYs//DFQirTG/fXjronNtr2xk?= =?Windows-1252?Q?WElXbkeAupbx4GpisfUuQJVgd5DXrcPHSNXvwHUusyDKBNQLe2Tbks1r?= =?Windows-1252?Q?hd1P/2UkOejzfI4e3qSUN7bsHenrK+8oS+94R3N25ror69O0jkIvvVQI?= =?Windows-1252?Q?MjozeMesGU3A+r0QIPHQ0l8ClND9U/NhwwvZWWVKh+UTKRDvcp1ajnkT?= =?Windows-1252?Q?PjuOjBXG9/4ENtTbNeUQhKIDHFW7v3JYlNFIGL+LLGPfhgnmd0AuHBCU?= =?Windows-1252?Q?l/YyAnD+Mg8X8QLSrPRrgzboGS4RvkNbPY6LNuey9GjplczL5LgwYgUN?= =?Windows-1252?Q?UnJY1de/1cDsvheQOxcLmYcEQz9TwluQU6to3f5+XYYq2Jp3usfRrwCv?= =?Windows-1252?Q?mbXP4JEhaXYioTELTSARVDXChNx+MWDsIziO638tY/oBy2ssdPHF/GSD?= =?Windows-1252?Q?lg3OHqqqniwmAJSfbf8+IH7K3z7rUT+0JbJLMo8Kj1aDZtafpPio/0NX?= =?Windows-1252?Q?RMrAc0W14gPOOIYRl1bR4r+5q48/s3g2AcfJp2ZavZirZQ2JYdtGgm7E?= =?Windows-1252?Q?CYF4Qx4tCju4Zehkyt9OrWGuO2xQPePBrum5rJTQ1vGN4XSV9QRaI0ez?= =?Windows-1252?Q?wKP06wd/i4TpoCFALwBnYKOKrZNcegQ0Dhzri+KYyXThajhT3zJg8A07?= =?Windows-1252?Q?iWk+9Spwejw54tfQP6x+XSFYbg7PlZ9kLsIdwXTmqS7YqH8P3TPsKQRx?= =?Windows-1252?Q?DYNz97rAaZlf/d9dPA3FMsFE4PbuyZ+LR8sgYgBnc246LhAMdDyvOIrG?= =?Windows-1252?Q?xO2unbVTH3QvQidZK3IndCuFibv2C+oY2U+VW/OLqDrAWM90FYGDuRnc?= =?Windows-1252?Q?pdalul3XzrPZg6y3y1XbIKJs47c5eThi/aWBePn76X+KHvbK9JgyXdmX?= =?Windows-1252?Q?3kh67Y7gb8JOnqdcfDdpBTkt4C9fwsJmYy9lKQBETEgvHrAm7E4WA+NA?= =?Windows-1252?Q?d7KUCZ1oJrYBELIQNz4TH6Id2s7GFfzNQaK/91E2bklPW/uBb/pADgaD?= =?Windows-1252?Q?Ve0KU1LNIRNlkfJGFcKpuHIm+KgwW4p0nTyS1p3HLTtqdHXAEabh2Qt4?= =?Windows-1252?Q?Y3JsR8V4Rs4NejMf2yw/SsIyXTV36WrEMyoJYoJRs3xdPkEwDPYibVX5?= =?Windows-1252?Q?8PcqILOvRWHhbsCV9YVjvjY71kWsDvggYAvZZvXheeJLj1Y6rSVXB7O3?= =?Windows-1252?Q?oDAGLdDPfjGZuNCJw23CaYllwt7LXI4/Smlkc8/XMV2oUABw=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1;AM3PR02MB116;5:7vxJeApQvMSd7l07DguFTEKyl8AJkTsGtWQp5vmLfQX6oEB+MKmuHBhWXuLPjRKF/srOqn7qUp32x7IWNJ7ZcM5buOqG2QEFZ9WwbVH5YNsV1QPe2RhDtKOqVU6z/ZdaYzlKEbUbT6SpeA/HEMBQ/g==;24:UFdNzqar76s5LNxIP4yMbdnEXJ+L0KjggaPlhDfBBCIWFzr/HIWNZtoMi0hxlzWp1q9iOQypBtTheiDfR1kErnEUQUT7LfnPUySb3LMsPVU= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: ezchip.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Nov 2015 21:48:42.3440 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR02MB116 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/24/2015 04:19 PM, Frederic Weisbecker wrote: >> Also, I wonder about the nomenclature here: other than cmpxchg >> >and xchg, all the atomic ops are named "atomic_xxx". For something >> >that returns the old value, I'd expect it to be atomic_or_return() >> >and be otherwise like the existing atomic_or() routine, and thus you'd >> >specify "atomic_t tick_dependency". > I think Peterz needs it to be type-generic, like cmpxchg, such that he can > use it on tsk->thread_info->flags which type can vary. But if we happen to > need an atomic_t version, we can also provide an atomic_fetch_or() version. Yes, I think my point is that Peter Z's version is what is needed for the scheduler, but it may not be the thing we want to start providing to the entire kernel without thinking a little harder about the semantics, the namespace issues, and whether there is or should be room for some appropriate family of similar calls. Just tossing in fetch_or() because it's easy doesn't necessarily seem like what we should be doing. > Also note that or_return() means that you first do OR and then return the new value. Yeah, actually fair point. I keep forgetting Linux does this "backwards". I still think we should use an atomic_xxx() name here rather than just adding things into the namespace willy-nilly. It's tempting to use atomic_fetch_or() but that actually conflicts with the C11 names, and remarkably, we haven't done that yet in the kernel, so we may want to avoid doing so for now. I can imagine in the not too distant future we detect C11 compilers and allow using if possible. (Obviously some platforms require kernel support or other tricky things for stdatomic.h, so we couldn't use it everywhere.) We could use something like gcc's old __sync_fetch_and_XXX vs __sync_XXX_and_fetch nomenclature and call it atomic_return_or() to contrast with atomic_or_return(). That avoids clashing with C11 for now and is obviously distinct from atomic_or_return(). I suppose something like atomic_fetch_and_or() isn't terrible either. There is boilerplate for building generic atomic functions already in include/asm-generic/atomic.h and that could be extended. Unfortunately the atomic64 generic code isn't similarly constructed, so you can't just provide a default atomic64_return_or() based on that stuff, or at least, you only can on platforms that use an array of locks to implement 64-bit atomics. Ugh. If we did this and then wanted Peter Z's code to take advantage of it, in principle we could just have some macrology which would compare the sizeof(thread_info.flags) to sizeof(int) and sizeof(long) to see which one to use and then cast to the appropriate atomic_t or atomic64_t. That's a little painful but not terrible. Boy, the whole situation is pretty tangled up, though. Unless you want to take a big diversion into atomics, I'd be tempted to leave Peter's macro alone and just write it off as necessary evil to handle the fact that thread_info.flags is all kinds of different sizes and types on different platforms, and definitely never an atomic_t. Instead just create an inline function atomic_return_or(), or whatever name you prefer, that operates on an atomic_t, and use the atomic_t type for your structure field. It's clearly a win to mark the data types as being atomic to the extent we can do so, I think. -- Chris Metcalf, EZChip Semiconductor http://www.ezchip.com