Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752759AbcDZMIc (ORCPT ); Tue, 26 Apr 2016 08:08:32 -0400 Received: from mail-bn1on0086.outbound.protection.outlook.com ([157.56.110.86]:65056 "EHLO na01-bn1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751750AbcDZMIa (ORCPT ); Tue, 26 Apr 2016 08:08:30 -0400 Authentication-Results: arm.com; dkim=none (message not signed) header.d=none;arm.com; dmarc=none action=none header.from=caviumnetworks.com; Date: Tue, 26 Apr 2016 14:08:09 +0200 From: Jan Glauber To: Will Deacon CC: Mark Rutland , , , David Daney Subject: Re: [PATCH v2 0/5] Cavium ThunderX uncore PMU support Message-ID: <20160426120809.GA9796@hardcore> References: <20160404121954.GA9300@hardcore> <20160425112207.GL16065@arm.com> <20160425120222.GA2552@hardcore> <20160425131907.GB30830@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20160425131907.GB30830@arm.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Originating-IP: [88.66.108.80] X-ClientProxiedBy: AM3PR01CA031.eurprd01.prod.exchangelabs.com (10.141.191.21) To SN2PR07MB2592.namprd07.prod.outlook.com (10.167.15.22) X-MS-Office365-Filtering-Correlation-Id: 02e91bf3-38fe-4a8a-3cfd-08d36dcb766b X-Microsoft-Exchange-Diagnostics: 1;SN2PR07MB2592;2:CiSsYJ/kckBBfnaVhPlVbQyOwHwGfRPsaWdh+Cs/H+RmhYT4m2bjGgtONDPtDlN306vQJzYuSxy8qcj0nc0taFHZZnMJgdjddclYOQ8QP7hsF5aGb++nVG5QwXym9+SKCdIkAI9vmLLpFI9QLQiALzL8nWA+48QnSukyfsh7Y1Na7DNVA7JHaS0NLNFwsJ/i;3:1gXML0JrwWlJWCn/lAJ5fLKaI3UoN8KtMOStivIOzeAEm+bXvOf4nLkIqVjXnN4GX8DTTOoGfgXTtCnVNWGGsGm4Q+yeYm4ObTNkIvX0F4MhdL1Jx0GDmbY3O2p1KiiP X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN2PR07MB2592; X-Microsoft-Exchange-Diagnostics: 1;SN2PR07MB2592;25:bQ69BH/cigQ4xHMCnsYOfZI1C83mNWID2XeShhHNjFZP/imosVzoNwT1k66LAVCy/rhSkoKfdIrrG4XDmX9i24C02S1IvBm24fuoTYmG3N+96Dyj3sHSNEDBTROJDJxQ/FkkLegxbtgqFbXYwBR6nJ1tWz0IEXe5nv9lGnh3APYGbnsu4KozqGe/SyuHQdCdDLfwgGP67GuTng369QL6Wla3IXzd2Pk0eccfkAmHQIcw8uo9aua64W5c72uWEQYOIuKwQNukU1R3edP2ibj1d0QD2ugDxPrWrUiN1gF6cjS2WhQuH5y9HPs2eUP/EBE24wEzCW7pwJNkwsnNo1855552KbW+7Y+wK1JUSzyQ8HFgtAmAmQpVqA8xlWYYV3zbMy9XcTvj2JJHNYfd0yeOKkTAtQbj7p7EFBOh/2AAK1Ho9Fboe/gONCriqNv7c61IgWBPc1uK8WQhYqr8nN9K2N0E1lpPeG8U2hktP9QZfQJfEzPVz3Sy0eDWmwGpsLhexsEOj1MlHbBXasiw0NiD+wUJSE6Ays6TmzRdPfMhng4cOaywSG8sKfJSXy1yMkM7aMflLmIT00/k+h+QerS2igxNe5UX+CuIRf5nk62KyB+J4pydhlXHTMyrzjIN4e2vfTtwK0jcNRiwxJ24pf2ncw== X-Microsoft-Exchange-Diagnostics: 1;SN2PR07MB2592;20:AnBa/LAp6XbZu+tZ0a9zUMxjtP+iEXJWyFXPUBBhij7yojxCOduLGWOaRebAwqs8u/f43hk4S4peL5CC3rhIp3zykMg6sMhyjH8Peks/Feo0qV2ZRACUSe/ZC65aVxkr/X4q+U7uHKWf7uf5yKg6QSVx89/fu3VRDLTplMcSW/+/I1aKDQlImwWMGmahY/nLXBv551c+kWQucpnE6msRStGcQ5OgHPQlyN2c+g3ZXUDBfqmwPJAGsQBJZfSgSv94YH1Vb+KoSXE0etI1+s6smSCyh1jY0uvqe9gzBhsN03gas2l7U+M+ytFjLAuR2t/BuS+TkStcyv5ds4Qd9P48riymIzGkuE7AqMW6hiFrXyrw78DDCNCjm9o9uxmqCNLOJPTE0BZipDx88T+R22NDOtghh4TBtOlXggCMvXSonxNw/GFwkj/OSLTBtduxUdksIkrpKXpojh1PsVzbY5LMys55RtNdvC87iY0GlwiKr15tBYdlkmRl0Cvn+IHlDSIOCjjdqq5Ciq/B0YNc82/KVxeJQRZbZRytWt8gllnLJY3oblk60/jAyfuvQwa6Bvj2dBLHJ2sQBhFdJkO79IiaS8929BBPnjAYJxMcec6xDYs= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(9101521072)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046);SRVR:SN2PR07MB2592;BCL:0;PCL:0;RULEID:;SRVR:SN2PR07MB2592; X-Microsoft-Exchange-Diagnostics: 1;SN2PR07MB2592;4:4z7HkB7K4MuIba8lNSUpz8R/XGWI/nvHrQw7RGSxxhL02hB4H+bnClh4myapG9kASnAO/ZjZVaanyNTmixz8e3lIfyQu7V2HXsRNk1euxicycCHmRVjMbnR5qcpAc6jSHBkOr+17wEFK1UyFa7tULd8TnNkOrQ8H7jkjoBlR1s2pHLeIYA0Pf8sS0sO6sYK4cns/fHB5hHzKhBgsymXqJsh4Ym5x+aJqk3QY2S3r/v6izxojcmnqZtc0jsId3+wmabPMBz71lewDJwpCvlHTD1kpIL0VzHILho9Bp0oK5ULWPEKGIPR1FAhJl7A9gYB1uk77k6tdG+siJHPzUJDB10qiUHD43OYfStB+J1j654+eKioCPDgkEKOdVu3pEHeZiqbi5t7/04fyGuG8k+CYBQ== X-Forefront-PRVS: 0924C6A0D5 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(4630300001)(6009001)(24454002)(81166005)(66066001)(6116002)(3846002)(47776003)(93886004)(92566002)(9686002)(189998001)(110136002)(33716001)(107886002)(23726003)(83506001)(77096005)(4326007)(54356999)(2950100001)(2906002)(97756001)(1096002)(42186005)(86362001)(4001430100002)(1076002)(586003)(4001350100001)(50986999)(5004730100002)(76176999)(5008740100001)(46406003)(33656002)(50466002);DIR:OUT;SFP:1101;SCL:1;SRVR:SN2PR07MB2592;H:hardcore;FPR:;SPF:None;MLV:sfv;LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;SN2PR07MB2592;23:eTfsvKQlCYxR9SgkVaQ9ty2o2jp4yV2AuqAUp5jn4?= =?us-ascii?Q?6yc9Afbe8lg7dLhWengFfmhVAPINJ0fIiVPzoIA/sQ2sqVlDHEL3KbLy4+fN?= =?us-ascii?Q?EEMvgCWEAV72aWIRw57taPKa+FxAzYTfZ5q/Zve2ckDpAWvXRT9OaA0fgN8Q?= =?us-ascii?Q?60oGv6rIiRQ2QA80TClrcSm2D3s5Wshe+wyAnow9Eo/KdUvDedTqV7f1U9q3?= =?us-ascii?Q?efNBBfZ0D5s2zf3AMMMBXnZo+gOeE0RkB+5epLL/igf18b5uwQ+dXGMDe5ki?= =?us-ascii?Q?/JcvTg5Q5ZT1KPCBvAFHkPwVD0gjU0TQp55nePq1OCcCPP6z8ap9TlAF/lus?= =?us-ascii?Q?3MisIpE3G+qCXQTtTJWGCuLMknjElIgvwfu2VogY6AzX37Yd42AQnH64CXFr?= =?us-ascii?Q?xuap9wd1cz3T2ciasapO1Ea4yhqXHETg49LNe9eEVjLAR7tnDc5GkD/8XTRE?= =?us-ascii?Q?2Mc0YEXWWaSddqJDsikYnyFGDBA7yGSUo63lzuYl7unwaqa8fy7MQkrPGLB4?= =?us-ascii?Q?E6cTZtSnavI7fQw25lkumBHkBRDLZk7FlYUaPX6+ZRtNWX1A7KwwBQQ/Iesd?= =?us-ascii?Q?Fttv5pLBLwhuIhqXjcvdvvtROTK49eMg1W1KoN2EgguyvRrtMZJCqycCvKvP?= =?us-ascii?Q?rp7jLDMH7X3rd9LGtjuj94jOU6MzSNHO0+1C+tn7Y0a3wHdoOemQfZ8kPKZM?= =?us-ascii?Q?XG6wzTeRMESkH63VUbkmEjfkUvNiE+uLGewZVemtCta4p+dzxYhUp6WvB/4N?= =?us-ascii?Q?ZFdvBCrQVKyRGUD2SNcmP2gu4efFdOiYydnVxRknwhzopkms/Onb4//2SWI3?= =?us-ascii?Q?9YtE+p8h4weoxpwmUCCGYZd1QttxE9OXgTWBxr4mL5wKSQL++6MDut12GkCI?= =?us-ascii?Q?EVnYwX5ujCaFOdvWCXoHpUlX6dTklY7D6qEQxpj04kaphp7dUb4Z7luPtWUJ?= =?us-ascii?Q?aTI200Y5SFNRfdKcvsqYGIWdNH4LVUKacEj1LS36YiOJ2QyrVZrMYZuRU78n?= =?us-ascii?Q?EI=3D?= X-Microsoft-Exchange-Diagnostics: 1;SN2PR07MB2592;5:iVsGeB1utWNPiPQInfJ/SoKaFaCvYXqjweruqKlDQLqcJkEQZNW5yDENgecl0Qw64+R8Y8Gs/HYWPIZGeJEfG8TibAljTxG1xW2iDufXa622Fm/4nsMCzW10NGyfDICFMklE9LubhCMytZxIqT40Sw==;24:bhbuSk8elXHNKJ29k0Ni5efjuMbh1xKX7MsGMhGwdQkyD0czVNlXUA3XU8URl4u9PwRv5YtbKZNh+WSda2Qxos8yyrFFF4sVN/xliqqlPoM=;7:0RN0XM+0TFVW2T/G7CsK02AdoBe6Wptf3Zt9fKV88y2FwlbJFKwUshl6wSbhGbP9MTlGOg64I/WU72GZ0IfxhgoZvz/g8FZPwkIh4VZHWvMD2NfN56mizLdYcSj+I5YaoCW0DBjym/VA1m25dfyhz4uxaz4YG5+S6S/vrrVMwsVDgsJDMu9Vrj2/Nvs06eWK SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Apr 2016 12:08:21.0024 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR07MB2592 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2192 Lines: 52 On Mon, Apr 25, 2016 at 02:19:07PM +0100, Will Deacon wrote: > On Mon, Apr 25, 2016 at 02:02:22PM +0200, Jan Glauber wrote: > > On Mon, Apr 25, 2016 at 12:22:07PM +0100, Will Deacon wrote: > > > On Mon, Apr 04, 2016 at 02:19:54PM +0200, Jan Glauber wrote: > > > > can you have a look at these patches? > > > > > > Looks like Mark reviewed this last week -- are you planning to respin? > > > > Yes, of course. I just had no time yet and I'm a bit lost on how to > > proceed without using the NUMA node information which Mark did not like > > to be used. > > > > The only way to know which device is on which node would be to look > > at the PCI topology (which is also the source of the NUMA node_id). > > We could do this manually in order to not depend on CONFIG_NUMA, > > but I would like to know if that is acceptable before respinning the > > patches. > > That doesn't feel like it really addresses Mark's concerns -- it's just > another way to get the information that isn't a first-class PMU topology > description from firmware. > > Now, I don't actually mind using the NUMA topology so much in the cases > where it genuinely correlates with the PMU topology. My objection is more > that we end up sticking everything on node 0 if !CONFIG_NUMA, which could > result in working with an incorrect PMU topology and passing all of that > through to userspace. > > So I'd prefer either making the driver depend on NUMA, or at the very least > failing to probe the PMU if we discover a socketed system and NUMA is not > selected. Do either of those work as a compromise? > > Will That sounds like a good compromise. So I could do the following: 1) In the uncore setup check for CONFIG_NUMA, if set use the NUMA information to determine the device node 2) If CONFIG_NUMA is not set we check if we run on a socketed system a) In that case we return an error and give a message that CONFIG_NUMA needs to be enabled b) Otherwise we have a single node system and use node_id = 0 David noted that it would also be possible to extract the node id from the physical address of the device, but I'm not sure that classifies as 'first-class' topology description... --Jan