Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S3000591AbdDZNmG (ORCPT ); Wed, 26 Apr 2017 09:42:06 -0400 Received: from mail-dm3nam03on0059.outbound.protection.outlook.com ([104.47.41.59]:18720 "EHLO NAM03-DM3-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1952742AbdDZNmA (ORCPT ); Wed, 26 Apr 2017 09:42:00 -0400 Authentication-Results: arm.com; dkim=none (message not signed) header.d=none;arm.com; dmarc=none action=none header.from=caviumnetworks.com; Date: Wed, 26 Apr 2017 13:41:42 +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: <20170426134141.GA6417@localhost> References: <1492623846-29335-1-git-send-email-ganapatrao.kulkarni@cavium.com> <20170420084928.GC31436@leverpostej> <20170424154530.GO12323@arm.com> <20170425165259.GS24484@arm.com> <20170426101021.GF21744@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170426101021.GF21744@arm.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Originating-IP: [50.233.148.156] X-ClientProxiedBy: MWHPR1201CA0011.namprd12.prod.outlook.com (10.174.253.21) To BN6PR07MB2995.namprd07.prod.outlook.com (10.172.106.13) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 9eabdffa-9583-484b-2509-08d48ca9feca X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(201703131423075)(201703031133081);SRVR:BN6PR07MB2995; X-Microsoft-Exchange-Diagnostics: 1;BN6PR07MB2995;3:IOQCe60zcphCqW9bAfty+Gkphtczx18xe+Z61Scf8qaKxmwHeWZcqP8oox4FRAnT1T7jCajRN49Pb/nMNjPKLTeh0hgduWk8JEKhnq9ZAp7JWtOhsf8jjmeVZ1EO/tEX3DnUn1xqZMGfhP4FzNOinCbb2JAu1Fa6plhUWCnt6uArwXkDHxzu9aok84GKpHMNfNv15k1bAi078htxF/PjXjCGRooN9lRRod84zbppo7vMBbNv1yJUBzBcQcLC9S0oIGWmPAYnQudsvSAnocWntvYyc8wHJH+ihiaH5t+kMa1KymYWtsLhvYr6AJ1rb/r5K3x1vorY5mpOBp7a4kGwxg==;25:PQxb7GdcsAWZ1HW5kxkAR4FDwbZg/mprS3A6q+K4Zu7w8+H0vhhXjyJVbYd/Sw+FFQ/860F919LKjtRlQHl/JyBPRJVcJoyygkV/UMFBAZ8bHtzAkQ/xHptMnc9iamGg/NO6Bt+V7yNv4uc38oQ/MtUJbVrh1qRPh+bw5/Le8Bs1I7VzJepJJoVBPYycmiDUihSgyvDJamn0wT22v98GWlbEBE3Qx52IPBhrwiYNWUMptxrhoQqcLOR5C3M7wZVTWBoh1uy7pxDoxVq7jyV2KBCGNi0RTtThnspCxgj2siH4LZ8YqkXGXM2k5GvwbtIlmNcLUafAoQx0wMd8xnVaVwVammjSoVFN3HIS3NP6UYWv2snW5yP1bpMgF6vlARE7TD6ZbGZ7Kyw4ccokjLV28pDmMBBn9uWOQ10xkeMsQkHrUNkwnrsokebYuuSIe2kVPsxuc4Z8Be3WB8jL4en6FA== X-Microsoft-Exchange-Diagnostics: 1;BN6PR07MB2995;31:V8wz4k2i66NQYunrVTyOwliirequdeewgN5bXKyVJ5Qpeqd1lwV0fAdKAPOMd6duP4RJhx8RI7ukrdyOeVB5nrgPt7lWd2SDVvL211UjRwEaRvSDgnHn7UgBFtoPtYlnQq1xG5p3IHvAXdgoALFkOxNvn2X8QROF9tRxmnRTvnPfwH+5U3P/z4LhJzJ21V3WOG89Gc1YAVHKKk3WVa5lDlf4iIsjZRfbLnYqtJI7PUI=;20:8p997GmqNVEjw51vvuqdfyQlbFZ3zLyDdab9Y6ErV5WucRld//gtciVACN0UOznb5Z5v49dJCIgISNxB8srxuyqCSMlGjQb37KQX7pYk4kcwzv1l7YPHMyXost8Qp7tg1Vv1TBu5eMY2LL4q+alu7p6hXhcagCixh+jdHattFTYP/QgpiiLVku11BOtRv6yYe3BAaRpAUJ/rUPFu0+xEiftMR9emCR9V0KBOaHLaH7qJJFZDXPtLU32VL0CQc/iMMeRe24x+Tf/s2nmtBrDWMDQ/eJlw+uSnuqXdw7fh/KEV7PTOe9PaR7GzemCiVtf+hphKTBOQjhtTIodCrOH8vszL0PLwPsidkZrK9qITYRIXviC5/ZLMoefkF+TOPFAF45UH0Y2y0X1+s9LbQ216HrGe7e5MBhEDjgpUlt++ECWdhoT3y4nnmI2AWj9H+w31uXU48lpdk6w/g2hbpucOV20n7oyhMDNwN9Sas4yKDpK4T4WTlViT9/JjumRgvpw5HT2XiNM1nUrpyMvgLaNgyzIJlPGV7ZdKow+Zxr4nHXNqhRUfrXYg0tKUmAdVVN0wogSwCA3wmpJBklWY30o9INfown+cxK5L6+GuW+zCiu4= 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)(8121501046)(5005006)(3002001)(10201501046)(93006095)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(6072148);SRVR:BN6PR07MB2995;BCL:0;PCL:0;RULEID:;SRVR:BN6PR07MB2995; X-Microsoft-Exchange-Diagnostics: 1;BN6PR07MB2995;4:zINXD30PdQkGK8lTur43nn40vvcW8RIXDW6wq4VsCFWpqoqUuKPrC6ao94bacddEwKvGz6xWsyBC9lrRTVwwqcOR/nplDFJPwkgeFWlAFkf9cTfTwEy7An5Ik1W4yD2A7y6pyivoQKAvI2eoedzm7VGynH6uJyjArog4n5reTH4l+TCmOkxUSqY7uYnrpjpncUOQaj3FuRUQenfL+P35/2kkcazFYM0WtM65EwxTiLHf5mZD5Ba8d+xo4SDXtVb2jsPGvbhRfr1lSe4HlQFUAw/w+WMcJgH4S2VJ5SUnM8jARhlssSHZ0fvuh/lYuVobsrjPrycbzoaGkWANeno4fqGEI/NLnKhN0LTCMorSNNJzH79XWgXPkJtrfBCa0Tp0xew46wQni57YqUVPzzHqskU9CsXcecwCP5aCE8tPzJVAMhU/pYV724Z+dNMOxDkjd68Ex+kWZ4HK11TTtfuv2mCIALF7y/6+LCZoCk3Kktpa2R6gKoqEQ8mymyBYonyT1JnbFjRxucGHpnlGh8BWE8vlGwKy6OzdhjKPJPDPoDAFF58Xii1+VOfh7POGQmoqoqEdvvaUwJHcx7ahX1KqOdJveCyqVXiaBx+oPPo6XpGjdqBQ83hEHZX0YJcn9/EYxkrpL939Ci7Zy7ZtILWG5dXU5bnZdV/rUzflICAX8TJNfjdCvz6Mt51bhJ7r38FYQ0EXVO65CglLmINhmyELxL1EKtgp0EYozuJ/ndBTHJPJ6omAg2wEvCsvlcT9RfMRdyzj9MTmNt2nZkl7Z8TwAd/fvgECjs6bjHLGMSOyJcER7/+uVlkoX5B/qTSQRy0r X-Forefront-PRVS: 0289B6431E X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(4630300001)(6069001)(6009001)(39410400002)(39450400003)(39850400002)(39400400002)(39840400002)(24454002)(377454003)(2906002)(81166006)(53936002)(54356999)(66066001)(76176999)(47776003)(23726003)(6496005)(50986999)(3846002)(1076002)(8676002)(7736002)(305945005)(6116002)(50466002)(76506005)(189998001)(42186005)(33656002)(5660300001)(229853002)(6666003)(42882006)(6246003)(33716001)(6916009)(2950100002)(25786009)(55016002)(4326008)(4001350100001)(83506001)(9686003)(93886004)(110136004)(53546009)(38730400002)(54906002)(18370500001);DIR:OUT;SFP:1101;SCL:1;SRVR:BN6PR07MB2995;H:localhost;FPR:;SPF:None;MLV:sfv;LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;BN6PR07MB2995;23:6yo5sTg/p6Rd/OCkzu0zXilucl6bIYD5BqMTDKrbq?= =?us-ascii?Q?R/MPAUSLdKdz2F4NHBUXmcNIUAtWSXkeoKtE/N63F82Htg0l1kjguyYf1wN0?= =?us-ascii?Q?rDB3YiKBW6/u5Smn7wCJdhAsQExGA3YhNm7h5r+j/ddBknnujTmQJFqdB/61?= =?us-ascii?Q?0/ofIHKMn4x6MehnVs0DRrcxvEP3aih5YLYwVGEPdaMBrAboldoVTequhasb?= =?us-ascii?Q?MDzglVdvmQ58XRMKJyyftDeXOBKzY/sVEg2u+3bNo+rUmYxJdRnkXNltEJUF?= =?us-ascii?Q?Hblwf5XPDjOhUmJmZwKbMq6xFAsMUt8/23fJY/UEhT6ZFlCmiGKwkrGW7r0W?= =?us-ascii?Q?3t+Iw/jzhK4p57bQYpdweJ5C+zxIo2InCVgldg/tg6CpVhSgyC7X7FvQHn29?= =?us-ascii?Q?u2fJxnc283lymYoT1hkMx5MJ/3eRqOdGvU690vN6itwnHcNgoTMVclbM9xX9?= =?us-ascii?Q?l1bwNzozs6Up31s1rCCWZZF65FhO1epjBJe85ftZ4umZBx2toG5wBf9NcSkH?= =?us-ascii?Q?1AlLu6es6Jx4QXXcrIEOPogT4RCKqtOPvaPnNIeXMpxX45R1+iNzsXTeRBAy?= =?us-ascii?Q?zuuy9Ofpai1HMi9Jjmv7oIcePZU2r60NbpWOzlV8iepp8UB8mQ/V2GuULRUR?= =?us-ascii?Q?mUwhmpWzbnYPIrKyyYRYhiE1k/WO2h54IuiIjGZN5sADxQLNREIud2Zlyzvx?= =?us-ascii?Q?4Xiv84C/SOKQPT7KGBhhDlyFz94KQJ4LCLNRUVtPRB/7NOZx+oGtuFRDwi11?= =?us-ascii?Q?hT+OxI0qbLxOhTVn8Wl5ZksBgWOUiaxjpI/Ued0EHz0pkp40f4Nc2gPj5VM5?= =?us-ascii?Q?H0J0XE9OEQWgIYKkh23cJxYPcX3weETUIPi8SUfuofRjM5elmX5GFu46/JSo?= =?us-ascii?Q?Wv7YzdnJ+xwBzV/Ay+OdlUxYFxZt2YfnlD3gMXWNB8XvIUoHUnIjKQ2MmhIU?= =?us-ascii?Q?xCVE3KetgxSQocBZIe4QefbEZ/sWIffEb6IMC3kGH/2p/tWoWtTYum/c7osC?= =?us-ascii?Q?8W6RYWKC+3FTzNrl73B4Co7xdKaB0xa67pZBndPhppiWFtauNccVVDXgqCn7?= =?us-ascii?Q?tN8eJjDUIcH+IV7nqqHV7RTb3ZGXOIDpbIYnyV6JP6XhlGznXlTSGemCDb/H?= =?us-ascii?Q?5c7ZAg1o5BQ07GL0KBT56SIGB1X64XfnHv2Gq9BMSX+6NR0iwXR+OQ4KR7za?= =?us-ascii?Q?D+45bXnxW/BTnbpAkYJAsOpHPleWAO6jQQ8H9Q//sgUaYNmLbb4N9BTUUAih?= =?us-ascii?Q?Snz9FJlrwf4oMZv1Ky0YV8zY5hncNSs/5Pgh3Ri?= X-Microsoft-Exchange-Diagnostics: 1;BN6PR07MB2995;6:wSJOXFdzOq5WSqz64+35opHn48pIZrPtUnv/unoiQ1aAAEXTGjFg8dufdN7biArC40s3Tw3e41TUhuBgwZlJXP5jLQm5uylHB8RmAmalNVnMhl3akjGOwvlApu3vP5uUam4SpnahrlMYDxDBRKUgdMaW3FoNQpRbfoMff2G5ungtYZPwllZWG2TMKB+JlGj5b+k0oLBzfi4ZpU/J/5D+/flYh7DPxvHNBMBQv6X/t0iYxJ8Y/xkbXhmTSDc/GIkzVs3kh6qAuP+o/NztyLKTF+XL8YJsE36cRnH95TemIW6jl8OjkRZ0oq9J+K1n4r9QxkoWzvz1UP/M9m2ElorxTnrqxQnZeaDJhoTLUjYZMtwYxLApWBeAk+Dd3MpL2J/zV6oeAms/poT7QYFYI5qKVrlhdGSv7d6ylRrM8cfayfmizcfDETmbsVrMgavRm3Qj/Ssi9/Cc26DIjHMgCIOl95ULc+RQ3hKjRATBXNVKby99XpVMOvxXmSThL/k2Kt/kSzFhnuDW7k2hGlGOYXiSiA==;5:NvVVOx/mnhb3ALu04+DEybY9H9pg1kQZKur16yRz2Wnc9FGaBruti2PCatuD23SAyPrbbRPrI/QbD2oYyo/ib4M1z2SVUfQcSWvHTrASt1SnICsqFUqMWuW56WHHCXT2NHDFjI8Cb279Va4yxZx7soPERLLGe/gWjzVZS9jBbtM=;24:TxNgWzDKhJ5Nxl2nllTEWWSWQDX8pQ+b5Jra54oV/QctkMdd+KZZbTzOmBH9BWSjwVPmWLro21UTDLmJWXSn/G5306x1wFyfVKxiYpAD8OA= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;BN6PR07MB2995;7:aerAstK5MfnLVSGxy2pekvu7Zk3v5vPUDUD8JQ+TPvs/PKpfcu0yBRkIaMqUesru3jO6y4Me3lUzasOBg8kqoL6k2yVN7otOxK+HM/X3hSVGQfZeNUHPC8l9pv/an4fOLCnNVmK+1pI+75PKJX4AB37eC+6rDcjdbdrdyoKO1l9oVmk1cH+tE9n04+EAKaHCLxtqk8bK89u5V0Xitu0b/eTnBcctPS1LO8BtfUSSuobY03jw3Gfa+Eqj9Y4LRS2vlplSMBRwYovN1ZfxJ/UE5YbDJzjQDNKLDG2RDIFxmpJa6AfKGY89RPJSowM+8IHU9NXwXhnfAJ3PyGcTM6Vpaw== X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Apr 2017 13:41:50.2621 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR07MB2995 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3673 Lines: 71 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. If that is not acceptable (which seems to be the case - but I do not see a reason for that), I think the better option for the application is to check if the platform supports the mode exclusion it wants by using the perf_event_open API itself. Thanks, JC.