From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1036027AbdD1Nqu (ORCPT ); Fri, 28 Apr 2017 09:46:50 -0400 Received: from mail-dm3nam03on0086.outbound.protection.outlook.com ([104.47.41.86]:32768 "EHLO NAM03-DM3-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1424154AbdD1Nqk (ORCPT ); Fri, 28 Apr 2017 09:46:40 -0400 Authentication-Results: arm.com; dkim=none (message not signed) header.d=none;arm.com; dmarc=none action=none header.from=caviumnetworks.com; Date: Fri, 28 Apr 2017 13:46:24 +0000 From: Jayachandran C To: Will Deacon Cc: "Pinski, Andrew" , "Jayachandran C." , Ganapatrao Kulkarni , Mark Rutland , Catalin Marinas , "linux-kernel@vger.kernel.org" , "acme@kernel.org" , "alexander.shishkin@linux.intel.com" , "peterz@infradead.org" , Ingo Molnar , "Nair, Jayachandran" , "Kulkarni, Ganapatrao" , "linux-arm-kernel@lists.infradead.org" Subject: Re: [PATCH v2] arm64: perf: Use only exclude_kernel attribute when kernel is running in HYP Message-ID: <20170428134623.GA85316@localhost> References: <20170420084928.GC31436@leverpostej> <20170424154530.GO12323@arm.com> <20170425165259.GS24484@arm.com> <20170426101021.GF21744@arm.com> <20170426134141.GA6417@localhost> <20170427173758.GN1890@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170427173758.GN1890@arm.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Originating-IP: [50.233.148.156] X-ClientProxiedBy: BN6PR13CA0035.namprd13.prod.outlook.com (10.171.172.21) To CY4PR07MB2998.namprd07.prod.outlook.com (10.172.116.12) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 6744d659-17ed-4365-8d42-08d48e3cfc98 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(201703131423075)(201703031133081);SRVR:CY4PR07MB2998; X-Microsoft-Exchange-Diagnostics: 1;CY4PR07MB2998;3:/eS8vyT1HrvHN7JZbVb0mUTjnwp6yI4WYepcYVcqrjHnitYonGomDGK9f8Zd8hljrqryWsO4Si3eFsvj3cR3zs27/lEHrAy0PMMyo4hK41jTePVPj3w2iMBvj7qEgVvBmBhgsASAFn51eRugEnTg9DIiEDTAt4CGGApRPRay30+pZk4IxB733FPf/1Qfj18U694Cf/EbjE8VEW2286VRxJSYa8X8yzVXKgxC4NpDJCbOFUnWury4fNMTG3Pw2yIndgFE5vwynQp18msxx0CA0tyJDzyDhUIkzPmrkmxeN1Oxwshg5kC46D6Gu3JMApDyIJGpWv68k2+2lpMyiBPbNQ==;25:ZQ0rI8FczK+OCbOdER/hb+mpaQV8OODfB8mI612f+nXl+8IFOiJ3At1nfhKDtazwA5OjC6H9rdQ6rDuKSPder5y17CzyCqYs57eYQ9Q5PvE5wm86ljXI68dlg7DVcfi+UpgyvhZcyun8+Foz1Q/dccjJGC2qIcv/GinI47FQJgupwvL+12z8U8yY/OaIEiItTyC3n8YGKw5VK/4esEnIG9AA9rYsnJvjiIvFqSnVUOX+OaQ957wd77OBSIAwNvv2xPYu8F0MgPZ2Hf3W892/VcL3CIvaOxG22Q52KH+te1QOBv/2M/FVPbaBO3d3/VR3QyjJYXubcP+pdWaAC0TVbBkUettMzDGB0Cx9RyNTxg3m4l6z4PsX+c3HOmIRdhDAzmY8+XqH/tsPmkeX+Nf02LbwNmzrzWTXT+FP3D7ZMgBgHBf3Gxo4Icalq9TaZWgOCqElYdqbEB9EJK+1Snrrmw== X-Microsoft-Exchange-Diagnostics: 1;CY4PR07MB2998;31:TT8k5hfsUk1dg7v1Q2AZqZ6QlObheyTi0y+tz/P5J6KgAZ5h6xr9J7wHmSIKEpStVPcZ6Pr306gFcBrwH40QZ3+JWrcOs35d8WXvZH9ro6/B2l9/nro2Dp/Gi9iujmHlByd5+TjDLWaF34HZfj6XauEygR4Nwx8bE8drecO36am5R1wY1/lPDchWbxkCzDsrGLJqiGfI8ga29WkNA/zQ8WjrrqSqiymT/vNnubALadVxCLzcJtnoajx+4d8bd6RT;20:Mc7EyxxpJWkAFYtSCvXD/VLa9bvK4koV6mREGm27S7+biiJ6ewANc6HLuXLzevYSwF23242mqHxm8xKQCIJM52X5BeZCZ7VffgYNh3zmASmc9TrXn4PiRC3NsbWJ0e+tImDzpMgg2K5IMz+v/CIcebI2mjOcgIilO6fhI9ErLMQaC4OJktpNCQBd0pn909PuBCyx/GYrKQ2iAvUqYdoDpMRUdAPpnFocu6gRpR915zebeOMeM0hTgwU35qKPxsGekKKu/VICOWEY9SgzI20oYRhHBeVyGOpey9mRlr8wXHd/sOEEPIpZqXZhBcQmuN5vOVwU+V+xxWf6XVdu/5Hub0CT8er+wiUD7vd1d/fCT2KdWIUe5OkgmdwMFfdNHlYaFo80J/x+N5MxJJ1J3v7YvcWm2XHAc1rSdSYw3swaYm6z0mZxXkoxpC2EVB/+cWL9Fkb74f/WiyiEgexUOVjFRMEVlodqAlbpdr8Q/2n+e714hjNFHGjkXh54PrmgTUb3pzjdHe5lX2X3BabpM+XXhJ8yXXmw3rT/waW4gtFG+iHlFR6kLwHeLIprnhRjS0vVj+5mKTjRQPRQ83aoUXGkj7Vmrinfp12WS9TXEJc/Gp4= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(180628864354917)(278428928389397)(81227570615382); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(6041248)(20161123562025)(201703131423075)(201703011903075)(201702281528075)(201703061421075)(20161123555025)(20161123564025)(20161123560025)(6072148);SRVR:CY4PR07MB2998;BCL:0;PCL:0;RULEID:;SRVR:CY4PR07MB2998; X-Microsoft-Exchange-Diagnostics: 1;CY4PR07MB2998;4:PdiwJYi6l1/RtcsHWRPkT4ipWt9T9KIvX9FrgQnMV1qw43egtBKnkD0YhbBj+mV9G5K55umPAwh06Njzw6gYIbOWNQzd/ZTl+cDmFTf9pzEGrxYoywTtO4yphZiLh05iRgfFbvMUS5RXt+p0+iEIvmxURJVRo1Td1R4AMkSfu/MQ67zUiRkTbM717rFRBAjyu5dV5y0Ev2Kp9AyKKN5ATD5K7ej4bx6l5Gy2tsikDcM8vgiv4x2QNYbSYQxu87xFKkxa9KLbHBnJtQdC/vLHHMOQ05qjfm4+7PSEf9nhD1uCJDfYb7nB9yGeD1ujnywctL5Soygb7IwM8AxXhdq4vjhujWFVrwhfFgULLi8wm1I51eAQDqm1lYrfZJzVVbVNMTcwoZjjMjqJUxHEyUIQNkUBG1yoGog+r98dYYrE7dFwqJAkMO16xpdcIJ47ryyJT8ZDCkn7o2BMcM9ExE1xUD/PE32KNXHVtxknoymEIEllZtcDWsOkJ5YSwaDXpIUegx2HHPVdOF6R+sTAtQv/V0jURZF6xtlDE4JUXdPFtBCqMlY2DGU+LL6D1N+btCpcnagJKiNJqxUBSNftGxNsEj0X3XwkYdlRqvyHSS5hn8w4EnYjP4yqBHCamB0UHtK8CBcHinfcUgxtO8fseL9dZXgXqKjx27IgyCC5r+G4AhR9m+4DpPaNZTAxbx0MAD8bcPn7dCkTJIA3pqqV7ilghxnIteDw8hr900GqXntWAGjdEOIwJ1Qg0PqTzxQig6HXOCwFVprclVrPfKz7pdUTNFmotH57HA0de7Zx43jU24qZiaUP2pXD9N7/Q9FdSPTJg1ZV7TGizCH3e7b5dGbpDQ== X-Forefront-PRVS: 029174C036 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(4630300001)(6009001)(39860400002)(39410400002)(39840400002)(39400400002)(39850400002)(39450400003)(377454003)(24454002)(229853002)(6246003)(76176999)(1076002)(50986999)(54356999)(4001350100001)(9686003)(7416002)(25786009)(6496005)(53546009)(76506005)(2906002)(5660300001)(42186005)(42882006)(2950100002)(55016002)(38730400002)(6916009)(93886004)(83506001)(110136004)(305945005)(3846002)(50466002)(23726003)(81166006)(47776003)(33656002)(4326008)(7736002)(6116002)(54906002)(33716001)(53936002)(66066001)(6666003)(189998001)(8676002)(18370500001);DIR:OUT;SFP:1101;SCL:1;SRVR:CY4PR07MB2998;H:localhost;FPR:;SPF:None;MLV:sfv;LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;CY4PR07MB2998;23:zLJVRpbqr7gKulIWYZaN96uYW8G9hYCNDAJp2y3oX?= =?us-ascii?Q?p0dEIoO2MAHY9gMP3dncEB3JVvLshNb6462h8+Fa6gnvYVjMHoUCV80lv3ER?= =?us-ascii?Q?znXHYoXGe5L4YkH75rLbpYMyilXhJIHNQ0Yyo/evFPxegTXsln0F7gB4Krbd?= =?us-ascii?Q?uVImoqqvjqCoe6Id52FRas3pcV3xeI+y+d+3wLZhCbtyObyPERgN2if2RfME?= =?us-ascii?Q?PylG+LnjZ3CGdEhqi4JindQZF0sYZOnoldRwM73TyVVgMI9FuOeFeBHbhWbM?= =?us-ascii?Q?c/+jeulcUJA3mef+AvF5s2EVK5QWk3RLVi70bTR1Qy54mqaHGYaXzcaQJbm1?= =?us-ascii?Q?J9yyRQD9SSn50XKD5QYjBfSKCjpXAqDyyzpABq8avqXxMmPsgKj6B4m8NwGG?= =?us-ascii?Q?cUdNoa21VJiM+SQNvptjTYgif5tU5Lbotn37r97yQ3IxraIMKzwsDM0NwdIY?= =?us-ascii?Q?afeRtWzGru76XjIbD0ZgAV0yFgKyG1nIzCPsqpUr81nIl8V/m69kQZFdridm?= =?us-ascii?Q?V+Yi8ktp1W0KxyKtyJpJcy4geTG5fUbR5XkvksJA/UuEg/F8rI2pUS5573GR?= =?us-ascii?Q?FhxDdWnWKJ2snd5MwAsZTdlkHJr8tx4h2sXRPf1zHFLtnyQPS0V7OLqAj+OM?= =?us-ascii?Q?P8sZNcBb3c3hkaoZ8ICYPCtao7P+l0Anh6l3nkM93sj+LxBuSH2ttRl5+p7J?= =?us-ascii?Q?S3xhDqUBxCpprMDdrIy+0GjE0MU65x7RXE/D1xi3q+fVrz1iLlLGV8uoc0D4?= =?us-ascii?Q?heYZ7XwYEC1imQVuWiVeED8LwygvDxx47SVkRXh5sU0sfJ3PrpB1ByUsd41K?= =?us-ascii?Q?lbqBPxIhVxkK6EFQwpnpTji1wYg1renRoOdsON/gNGA7+eJ5XY9ZkxfPUIB4?= =?us-ascii?Q?vy3axFzBJllc7Ks17slHjvw/hemxij7Ic4R26V5+HURbX6YaLFWlpJ7qtDXG?= =?us-ascii?Q?QhgP8CQnN4EcmUHi/dkYzNfbiI6U5LUdkuaUbPMneIpq8pDpy4XfAzZfNgGH?= =?us-ascii?Q?BKMQsFoZfPYoCiIxL/ANQSIIPrF9Fhqfy39Sbm+8YIZ4YkdzxDUi0LIfwHMc?= =?us-ascii?Q?CCPOWgmTdWmsXNwyqTpw1YZjcZRlquvAOWUZv/ke5yDHdvV1ZtqahpYzd4U+?= =?us-ascii?Q?FasmglE/+emh2JFFHfCqyltxQTWA6OHH8joOmDTG35rknbND5QhPq9RYtM8m?= =?us-ascii?Q?be9KtOo9+/e+WExhIQY8Mba07wG0G1tZfhU5vm7geG2b8lxTx+lQgVnZMh+s?= =?us-ascii?Q?8IOevWd2MTHbO05RxRDIsxv93rwkADeVQfiAKg5vYKi3cU8Xtudla9YIpsyL?= =?us-ascii?B?QT09?= X-Microsoft-Exchange-Diagnostics: 1;CY4PR07MB2998;6:qKYJO3nxjEhoFVXBuDuRMozFPvdAd9oIWlHv7ITeoDMC71LUS2AP8vu2XjwvZNDNCDzRgeutfktCwQDdTdP8BZZHX6IYffxbPhbkD8gMOQxlobVAKfYMMw8Xsw3sX2vdcD7CVQXL/MbwmVuvCLd8oX88EnuNICMazTknY4jxOmHxBvqlyEkz+7BTNNSUukvxGA/zENF12JtVrfluNv+LOqOJJ9wsOMMqVh1+7TYK7otVaKNVoTSnIu8MESzIWzLlnzKyZ4CPv7dixgDa+cCrkrbpl0DAO/YclseWeOh4euDtBrXqllt/VcGNIQWQSWhr55TEaHfQv1uvMdxxmNQKl4Q15jbPljQXt1Nq8wc7w91eo3TINWtjleqfnHsqNpIov+3sy3WgATgEGUgjHd9BprfUEd+q/BfkkhacQs30C8NcNPV34gHIPkjJoC0598ULfzBGWIXTtNTjkuFuPKiazqHA7M7yC5tA1CRmpLGmRZl/l+PqB2423E9B/zla6J/4bjZ+W/KRPURWaLtchHWUeA==;5:4YX8aMjFS8LpnYl9NwkVxZvFqWds0mC2YCYfXVxn8OQLwcdqSf4Noa3EaLfBHzw2tSorb0t8WxA7PlzpzKPyoXBS4kViwM1Do01ADaMgKgcd+XTCXVAs7X9zAIWZmss/M2drK2QpI0FL4g1tAudv4w==;24:icnevB35HZoJf0Tgn2YRrBztgub2Gag3YzsZ+TJ+gcgsX7yuLLd80z7Grn6pDYRxXjrjEYREx3ZWcA90FWcNGA8pguNnLI03uA3Fc9QYxQk= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;CY4PR07MB2998;7:pLYgflb2WWWnJCsO3pwZcT+2NTip0uAoCq9O847j7r2vkSi+4Sni3DNFwY02p1tu6BquQppo3MfevnIAfXh9D2NHVpccDeK3cZtJ8xizCWL+IxEbRUFH/15wZaOt8O5iqqqG3uxHud+4fewYxN2xYcWfeIHqhnRYDrv3xGcguzemox79DzYVHaqsEmefq+GX7itbdDiWvN1A6nvxfBWB11ZY2DGXpGesBolnbPg8KAZ4dVM8GSHCXkflO5bXb2l+wH0/2Ba/uTsC6VSmat5siTsOBCfyR7+FjxXo+ZEAjiTVyj2TTvA1A4gkMdL1F7wPCGy07ZHA3G8URZZzxZoEIg== X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Apr 2017 13:46:33.2733 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR07MB2998 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 27, 2017 at 06:37:59PM +0100, Will Deacon wrote: > On Wed, Apr 26, 2017 at 01:41:42PM +0000, Jayachandran C wrote: > > On Wed, Apr 26, 2017 at 11:10:21AM +0100, Will Deacon wrote: > > > On Wed, Apr 26, 2017 at 07:22:46AM +0000, Pinski, Andrew wrote: > > > > On 4/25/2017 11:53 PM, Jayachandran C. wrote: > > > > > On Tue, Apr 25, 2017 at 10:23 PM, Will Deacon wrote: > > > > >> On Tue, Apr 25, 2017 at 09:13:40AM +0530, Ganapatrao Kulkarni wrote: > > > > >>> On Mon, Apr 24, 2017 at 9:15 PM, Will Deacon wrote: > > > > >>>> On Thu, Apr 20, 2017 at 02:56:50PM +0530, Ganapatrao Kulkarni wrote: > > > > >>>>> OK, if you are ok with sysfs part, i can send next version with that > > > > >>>>> change only?. > > > > >>>> I think the sysfs part is still a little dodgy, since you still expose the > > > > >>>> "exclude_hv" file with a value of 0 when not running at EL2, which would > > > > >>>> imply that exclude_hv is forced to zero. I don't think that's correct. > > > > >>> okay, i can make exclude_hv visible only when kernel booted in EL2. > > > > >>> is it ok to have empty directory "attr" when kernel booted to EL1? > > > > >>> attr can be place holder for any other miscellaneous attributes, that > > > > >>> can be added in future. > > > > >> Sounds good to me, although I'll seek comment from the other perf folks > > > > >> before merging anything with ABI implications. > > > > > Do you really think this is the solution given: > > > > > - this is an arm64 specific sysfs interface that is tied to the perf API > > > > > > That's why I want feedback from others. The intention would be that this can > > > be used by other PMUs as well, since it's not uncommon that parts of the > > > sizeable perf_event_attr structure are not used by a given PMU. > > > > > > > > - the perf API documentation has to be updated for this > > > > > > So? If having to update documentation means we shouldn't change the kernel, > > > then we may as well all find new jobs. > > > > > > > > - All the applications that use the perf API have to be modified to > > > > > check this sysfs interface > > > > > - If the application fails to do so, a very narrow corner case > > > > > (exclude_hv != exclude_kernel and VHE enabled) fails. > > > > > > See below, but apparently people care about it. > > > > > > > > Any application that really cares can already do see if exclude_hv != > > > > > exclude_kernel case works by calling perf_open_event() with those > > > > > options and checking the return value. > > > > > > That's a good point: there is *something* userspace can do, although that > > > would be arm64-specific and doesn't really help with the state-space > > > explosion you get with combinations of invalid/unused perf_event_attr > > > fields. > > > > > > > An example of an application which needs to changed is HHVM. Currently > > > > it sets exclude_hv to true but exclude_kernel to false as it does not > > > > care about the hypervisor associated perf events associated with the > > > > code, only the kernel and userspace associated evnts. > > > > Yes we could submit a patch to use the sysfs interface to check but it > > > > would look funny and the facebook folks might reject the patch as it is > > > > ARM64 specific in generic code. Note this is how all of this discussion > > > > started was HHVM's call to perf_open_event was failing. > > > > > > Hmm, if you're saying that HHVM won't be changed to use the sysfs stuff, > > > then why are we bothering? > > > > > > Not sure where this leaves us. > > > > If my understanding is correct, the sysfs suggestion above is going to > > add API complexity without solving the issue. Ignoring the exclude_hv if > > it cannot be honored would be a better solution. > > Better for HHVM, sure, but I don't think it's better in general. It means > that we silently do the opposite of what the user has requested in some > configurations. If my understanding is correct, when is_kernel_in_hyp_mode() is true, the kernel is in EL2 and there is no real hypervisor with hvc calls from kernel. Ignoring the exclude_hv would be correct. When kernel is in EL1, it would be correct to consider exclude_hv to skip events in EL2 (reached with hvc). I don't see the issue, can you please give more detail on the config with unexpected behavior? JC.