From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751236AbdHaLf0 (ORCPT ); Thu, 31 Aug 2017 07:35:26 -0400 Received: from mail-by2nam01on0040.outbound.protection.outlook.com ([104.47.34.40]:14112 "EHLO NAM01-BY2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750990AbdHaLfY (ORCPT ); Thu, 31 Aug 2017 07:35:24 -0400 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Jan.Glauber@cavium.com; Date: Thu, 31 Aug 2017 13:35:08 +0200 From: Jan Glauber To: Suzuki K Poulose Cc: Mark Rutland , Will Deacon , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Borislav Petkov , David Daney Subject: Re: [RFC PATCH v9 5/7] perf: cavium: Support memory controller PMU counters Message-ID: <20170831113508.GE15906@hc> References: <20170829131238.4988-1-jglauber@cavium.com> <20170829131238.4988-6-jglauber@cavium.com> <09997d9f-0003-0eb0-63d1-9b31e26e2229@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <09997d9f-0003-0eb0-63d1-9b31e26e2229@arm.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Originating-IP: [88.67.130.225] X-ClientProxiedBy: VI1P189CA0024.EURP189.PROD.OUTLOOK.COM (10.165.188.37) To CY1PR07MB2587.namprd07.prod.outlook.com (10.167.16.137) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 9fd67915-2e0a-4c3d-591c-08d4f0645d20 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095);SRVR:CY1PR07MB2587; X-Microsoft-Exchange-Diagnostics: 1;CY1PR07MB2587;3:i4iweamjgGOWjyTjFRUkSARMw3NjILbneytR+CCPpKNCPwzhtv9/76aPgBA5E+dfVdKB9HaDOMHPdTO95/aI5wRlDpbPhBS+khcTtusKWpp3twhxNJsxLQUm1UcWh9PNsw2QLTNExLPttRatPkhl8pqxXp5guFXy4Pwss+f61uC9dLo6wWP0Yawf/Ipg/2VQeF12JIwmrMXQ4QBAQr2sS+PLYZXSIWZk23M/gIe9HjrnpGBI1wVEGVBdXk5SJM98;25:OiKY9l3B6GHoj0KfR47qNNBUteT/6788sRnzOw5tJ/7YL2s3u7bmyQfpoxhg35cZmiD41V//BulbYbT2FCDzuSqd11OBNYj2eR7p9CeztC+iZfOvYlSB7KXoztsxANOI7NEfmcXTffA4bs57PawRSFwOxXCNqs+9beTP3qpDyRA96Lj0ATcwIZcTT3jOJ2NcP7xiaba34xm83/xiWx3QMrSKM8rt+8mPiRI8uut7ms0y7fN540RKMjssd1ibficw+nJKUoA0S3bqgXGQEtl9qfzxiltzEb/1O+lkgQAg1La4LuLx/XuynmHGtwU1tvVsiNkpLnnSEPxY5MNnu8LPAw==;31:de3KZ7Rafg622aJd0acI2HevI3PSnDFMCOUkGVp3LRK0uyf7vURX19OfMZnc6ehowGBEKd158JYC1+4oxWv1YTstjhOcHdPWjolHeQjvOb1p5lEUrIN6Ou6gPMB7uGPjEtcMhAQMoh8cAg+orNQHjpt9l5v6yir2Ji+Mydg7e/O9x7L0jc97u8kj6fNo6ACRO3wMRw9kVdajjc3ucz5GhMIw1ur1YspDflcTnW+Zf40= X-MS-TrafficTypeDiagnostic: CY1PR07MB2587: X-Microsoft-Exchange-Diagnostics: 1;CY1PR07MB2587;20:YTCFA5VPbZw9SGDcMayVMG9mUpofCevwv2giM345fc7956Fn3tO09XBlCftAsngjJskC5MzEeA2gVCqeCfJbZgkyxL741rCyhWEpn/AUL6MiNzGNPLpuAbvt8ixCr5crgERKFrOl7wW0YNoPrRt5jgKtmrD61h3zyncqkVrUVaZGeN9U8DN/sE+56FSJ+Z2LEqh5jmoyzYaaCwkrveemF49OwTG52PItVk+r2XKfA1GrG/HWKh9fJzQ7VQKtzXk8g1jAbAOUSemENGKI5EzKP5SH2W9G1WuSJSrhLBTOuyMMcpzXE4Mkh07gpjs8sc16rzI+DVyiousm2TWrilOVgQ8v+GKXtTwmMdZ4hvBWWpyNE88ONJI9PKjFt5BLqO/7hm62NIevExgi4PUkbe8CwSLt/CnkzwYLPaMXev7TcPaxCGZsewqfgF+mty4Blsoiq7upedbvb4nqDM1RM4TM+C8GiEgCWgUMxyictz+NVpV3iSmZ0+r8c7drq72Dno1bU+4PGnkHazhSTPj6kuCQ36tBtNGJ01O5OudnvHIG1k1XCrMc0LE5FwT3QIMv6bjMO5dFRykZpKfpn/yfI7KADWEvRUwNb/ycUpq7hxr2W9U=;4:la9MfSFOT+O3uDAnB1mQWmZW9GsqidWbwDZ38xqegGpsJHr9I8xHcOTClI6jVrCPz0UsWtRIkPg9rlTZZdOn1w6moxNQJlLYJIFCcac86a0H02kk6oDGZvXfcN77MxpK1CmpFiUnOHzSF6Ex77pOjEBhwuIo0ng12ZtMjSGiBLu9nkpZxPjK9MIeAk/0w2nDfPql4DXpomIeTFkSFEBgS8lEK79dtxfHZupwa77Wkt12bOcaX5V4loIw/NJ3vhN2 X-Exchange-Antispam-Report-Test: UriScan:; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(100000703101)(100105400095)(6041248)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:CY1PR07MB2587;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:CY1PR07MB2587; X-Forefront-PRVS: 04163EF38A X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(6009001)(189002)(199003)(24454002)(33716001)(110136004)(106356001)(229853002)(105586002)(54356999)(6666003)(9686003)(53936002)(6496005)(6916009)(54906002)(55016002)(42882006)(66066001)(81156014)(81166006)(25786009)(42186005)(101416001)(47776003)(76176999)(2950100002)(2906002)(107886003)(6246003)(33656002)(305945005)(8676002)(7736002)(50986999)(68736007)(6116002)(23726003)(53546010)(3846002)(4326008)(8936002)(189998001)(97736004)(4001350100001)(5660300001)(50466002)(83506001)(72206003)(478600001)(1076002)(18370500001)(217873001);DIR:OUT;SFP:1101;SCL:1;SRVR:CY1PR07MB2587;H:hc;FPR:;SPF:None;PTR:InfoNoRecords;MX:3;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;CY1PR07MB2587;23:GJQwbioV3ijH4b+bh4Agn7mvRkjR9ExQEKD2oLhly?= =?us-ascii?Q?dfMcsSesjEnMpRTHpKk93TBgNve/fJrlOox9IeBel98TfTir2h3N5FYHUZG/?= =?us-ascii?Q?hMc5ge56nkO8HFYkOFcH1McUNfjYD5aPO46Vj83hrm3TROO9QqXNzpvB25Zz?= =?us-ascii?Q?+7pt0Lz9Kf5Jj97FIykZachVUdZEqy05QcZU2w+4AdUzTEsoBwH3Ctm+2h9N?= =?us-ascii?Q?/bAQuZ12hP7C05RFLe+qo7oGdKm8ZUgTV6YL3mqBNN2+tuDmX0/jvNhRYLn+?= =?us-ascii?Q?OYwcpLc3Qbdxvi+SNMZ26T1Bi/6tPU0UOMu3NfwVZPFv0OFMWRFQLeIJEir4?= =?us-ascii?Q?aRgtfZzzUkMNSIlOSh3jlDQftB+5FXVuZT8p96BOg6D4GLTtfMo7zHK9iR7R?= =?us-ascii?Q?Y+NTUtkQ7rCndquHkv0y3u+qnIu2Za3PxUJL/vFXRbGHrRTq4DUqQ7pDV/LU?= =?us-ascii?Q?oUTrX3EyAYrbCJDGVanNsDn8qcsn+KZpAl/GZBuXNBP6RppkpxGC006kLSvj?= =?us-ascii?Q?Mx4m6bCZmSnK2zXDqHut2f2Z+zuGQHkQADvu3QwTA+/UrMiv3iLiR8FWsnqI?= =?us-ascii?Q?hFGuMCaijwAvDJHSD0ZtbKTRSu6XqUo1Xtyw13O27hbntLmdJnYaLbXwvaHm?= =?us-ascii?Q?2aLEZ7uzZnALkax4iKgcx6DhFgGjfqWpWseDXjaZClc4ikxtQ++81GSB3Vye?= =?us-ascii?Q?uNMCggry45SOfziS6hzGOHelo8m/l57zHjeykvIdklI8mtcrL3CQ2LdLEWKo?= =?us-ascii?Q?AOLjwE1NBMeQsJEgfiv3M1fns3iDgpmOp9EkRxfs2w8ye8W63OoXYwTMTMsB?= =?us-ascii?Q?ra1dEEnqOvDQoeKxpx+HEyhQEXpnGRyA9c07ICTr9dzqY0NOjHmhyhtuvv2d?= =?us-ascii?Q?ChR+H1Aq6DCmw4aX0nbsR0/wo2LsXmLZaEcBSWsX1q/1NgNMRkibdh/QSPTE?= =?us-ascii?Q?mEQiThc0PFnq8U/gLTHY2OQhpVAvJ461hJLjxPRPHpOeUw2779yEzpBDdAzA?= =?us-ascii?Q?QYTTx8D3Z0DLEaCFlmN07gFdw1tN59KIZBrAR//kEsVp5NSGSA9UXJIFhhak?= =?us-ascii?Q?sbAIon0Nyi8R9jINj22vYQOKdjfTWVVmOJagau7GWhpAYTMh+brcjfnF2wvz?= =?us-ascii?Q?WLttPftlAxmHJfEFNdUEwASQB6NeyllVLLs6SUEX+fIoAnq4G1ipj9TFE5LK?= =?us-ascii?Q?7gKWE5CgMViq+ngmKcIRJH3fKYCyS8+zcA4ebaNaYyPOASWYnx8Qm5tWkuvU?= =?us-ascii?Q?4lJF/uLBOyg2DPc8ac=3D?= X-Microsoft-Exchange-Diagnostics: 1;CY1PR07MB2587;6:NGIjY/nTbmqUa43YunAT78I87f7Arl3Agk5Au9W4J7CKYzt3WPSywtS3wQ2HOqK8K2t+DwaS3322g60robib8MmSuYf1FPqJqOCrPxy9G10NpXTNqlxIeaH+pneEO4rwB4l1tph1ag8KHcQV+boUgx+Nc7Z8bA0mplfL8R5f9+XZQIj3iYcNHu0FNccvbcJTOHoFepDSLqsehaYOwaXZv1j3CXYXQ3HL6WJH5HbQXBx1RXPoCeJwjIoRIuyNlXCZoVOXpLX9Ho6TYlc2PTJRDome9UnftXe1ykX/VSTsSfitGfN5E6wWKcU1vgPHiTUOnh1xg6nBWB9lXHb8m/qdGg==;5:WcGrUotZqvf1SF022hetqFlI78JcMTuV/OA1yhqrikv2JmrhSx3wqkUZ5ux++JiNT5psflGOlfropqSd/xBDQdwXsbMDGpt/4xGwv4qPTppigyuzQ6LMPQ+u434COPRvHIO/SbeDcChXnm6vZk1KJg==;24:l6rExVVvZi7STlIcV7NhJYkW4bBQOQRKFBKxUqfvaSIzOEyR2UoZs6pWdplfWZavCob4FIoodnvqOBolWQfUvmPFzFNz6Vwe6uxlteuc/t8=;7:h2IGfnK5pGnDvuamAPKxTttwRmpjV59I9E9CUbhtiICNtLTcRllQkExvXgvGkFclCyjrsZbAhgvWgyCfYVveiO+FvMllQ8ydztUeGNsTjWqh3HX3IASZvtleuWphePjkmpJhD2gZxCcdDn43IPUm9Bsk6roGae1zaTm3MUJJ9yUhW5dmIdduaVq5YQJ0oCA/Q93+UijkRtn16KR+3b3Q+bpQ30L8OVbrqA6Nezzl7p4= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Aug 2017 11:35:19.7910 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR07MB2587 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 30, 2017 at 11:03:00AM +0100, Suzuki K Poulose wrote: > On 29/08/17 14:12, Jan Glauber wrote: > >Add support for the PMU counters on Cavium SOC memory controllers. > > > >This patch also adds generic functions to allow supporting more > >devices with PMU counters. > > > >Properties of the LMC PMU counters: > >- not stoppable > >- fixed purpose > >- read-only > >- one PCI device per memory controller > > > >Signed-off-by: Jan Glauber > > Jan, > > Some minor comments below. > > >+static void cvm_pmu_del(struct perf_event *event, int flags) > >+{ > >+ struct cvm_pmu_dev *pmu_dev = to_pmu_dev(event->pmu); > >+ struct hw_perf_event *hwc = &event->hw; > >+ int i; > >+ > >+ event->pmu->stop(event, PERF_EF_UPDATE); > >+ > >+ /* > >+ * For programmable counters we need to check where we installed it. > >+ * To keep this function generic always test the more complicated > >+ * case (free running counters won't need the loop). > >+ */ > >+ for (i = 0; i < pmu_dev->num_counters; i++) > >+ if (cmpxchg(&pmu_dev->events[i], event, NULL) == event) > >+ break; > > Does this mean, it is the only way to map any given event (for programmable counters) > to a hardware counter ? What do we store in hwc->idx ? We have 2 additional > struct hw_perf_event_extra fields. We should be able to use one field to map it > back to the counter, isn't it ? Hmm, I might be able to use hwc-idx directly instead of the loop, will check that. > >+ > >+ perf_event_update_userpage(event); > >+ hwc->idx = -1; > >+} > >+ > > ... > > >+/* LMC events */ > >+#define LMC_EVENT_IFB_CNT 0x1d0 > >+#define LMC_EVENT_OPS_CNT 0x1d8 > >+#define LMC_EVENT_DCLK_CNT 0x1e0 > >+#define LMC_EVENT_BANK_CONFLICT1 0x360 > >+#define LMC_EVENT_BANK_CONFLICT2 0x368 > >+ > >+#define CVM_PMU_LMC_EVENT_ATTR(_name, _id) \ > >+ &((struct perf_pmu_events_attr[]) { \ > >+ { \ > >+ __ATTR(_name, S_IRUGO, cvm_pmu_event_sysfs_show, NULL), \ > >+ _id, \ > >+ "lmc_event=" __stringify(_id), \ > >+ } \ > >+ })[0].attr.attr > >+ > >+/* map counter numbers to register offsets */ > >+static int lmc_events[] = { > >+ LMC_EVENT_IFB_CNT, > >+ LMC_EVENT_OPS_CNT, > >+ LMC_EVENT_DCLK_CNT, > >+ LMC_EVENT_BANK_CONFLICT1, > >+ LMC_EVENT_BANK_CONFLICT2, > >+}; > >+ > >+static int cvm_pmu_lmc_add(struct perf_event *event, int flags) > >+{ > >+ struct hw_perf_event *hwc = &event->hw; > >+ > >+ return cvm_pmu_add(event, flags, LMC_CONFIG_OFFSET, > >+ lmc_events[hwc->config]); > >+} > >+ > > Is there any reason why we can't use the LMC event code directly > here, avoiding the mapping altogether ? I wanted to avoid exposing the raw numbers (0x1d0 - 0x368) here. thanks, Jan > >+PMU_FORMAT_ATTR(lmc_event, "config:0-2"); > >+ > >+static struct attribute *cvm_pmu_lmc_format_attr[] = { > >+ &format_attr_lmc_event.attr, > >+ NULL, > >+}; > >+ > >+static struct attribute_group cvm_pmu_lmc_format_group = { > >+ .name = "format", > >+ .attrs = cvm_pmu_lmc_format_attr, > >+}; > >+ > >+static struct attribute *cvm_pmu_lmc_events_attr[] = { > >+ CVM_PMU_LMC_EVENT_ATTR(ifb_cnt, 0), > >+ CVM_PMU_LMC_EVENT_ATTR(ops_cnt, 1), > >+ CVM_PMU_LMC_EVENT_ATTR(dclk_cnt, 2), > >+ CVM_PMU_LMC_EVENT_ATTR(bank_conflict1, 3), > >+ CVM_PMU_LMC_EVENT_ATTR(bank_conflict2, 4), > >+ NULL, > >+}; From mboxrd@z Thu Jan 1 00:00:00 1970 From: jan.glauber@caviumnetworks.com (Jan Glauber) Date: Thu, 31 Aug 2017 13:35:08 +0200 Subject: [RFC PATCH v9 5/7] perf: cavium: Support memory controller PMU counters In-Reply-To: <09997d9f-0003-0eb0-63d1-9b31e26e2229@arm.com> References: <20170829131238.4988-1-jglauber@cavium.com> <20170829131238.4988-6-jglauber@cavium.com> <09997d9f-0003-0eb0-63d1-9b31e26e2229@arm.com> Message-ID: <20170831113508.GE15906@hc> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Wed, Aug 30, 2017 at 11:03:00AM +0100, Suzuki K Poulose wrote: > On 29/08/17 14:12, Jan Glauber wrote: > >Add support for the PMU counters on Cavium SOC memory controllers. > > > >This patch also adds generic functions to allow supporting more > >devices with PMU counters. > > > >Properties of the LMC PMU counters: > >- not stoppable > >- fixed purpose > >- read-only > >- one PCI device per memory controller > > > >Signed-off-by: Jan Glauber > > Jan, > > Some minor comments below. > > >+static void cvm_pmu_del(struct perf_event *event, int flags) > >+{ > >+ struct cvm_pmu_dev *pmu_dev = to_pmu_dev(event->pmu); > >+ struct hw_perf_event *hwc = &event->hw; > >+ int i; > >+ > >+ event->pmu->stop(event, PERF_EF_UPDATE); > >+ > >+ /* > >+ * For programmable counters we need to check where we installed it. > >+ * To keep this function generic always test the more complicated > >+ * case (free running counters won't need the loop). > >+ */ > >+ for (i = 0; i < pmu_dev->num_counters; i++) > >+ if (cmpxchg(&pmu_dev->events[i], event, NULL) == event) > >+ break; > > Does this mean, it is the only way to map any given event (for programmable counters) > to a hardware counter ? What do we store in hwc->idx ? We have 2 additional > struct hw_perf_event_extra fields. We should be able to use one field to map it > back to the counter, isn't it ? Hmm, I might be able to use hwc-idx directly instead of the loop, will check that. > >+ > >+ perf_event_update_userpage(event); > >+ hwc->idx = -1; > >+} > >+ > > ... > > >+/* LMC events */ > >+#define LMC_EVENT_IFB_CNT 0x1d0 > >+#define LMC_EVENT_OPS_CNT 0x1d8 > >+#define LMC_EVENT_DCLK_CNT 0x1e0 > >+#define LMC_EVENT_BANK_CONFLICT1 0x360 > >+#define LMC_EVENT_BANK_CONFLICT2 0x368 > >+ > >+#define CVM_PMU_LMC_EVENT_ATTR(_name, _id) \ > >+ &((struct perf_pmu_events_attr[]) { \ > >+ { \ > >+ __ATTR(_name, S_IRUGO, cvm_pmu_event_sysfs_show, NULL), \ > >+ _id, \ > >+ "lmc_event=" __stringify(_id), \ > >+ } \ > >+ })[0].attr.attr > >+ > >+/* map counter numbers to register offsets */ > >+static int lmc_events[] = { > >+ LMC_EVENT_IFB_CNT, > >+ LMC_EVENT_OPS_CNT, > >+ LMC_EVENT_DCLK_CNT, > >+ LMC_EVENT_BANK_CONFLICT1, > >+ LMC_EVENT_BANK_CONFLICT2, > >+}; > >+ > >+static int cvm_pmu_lmc_add(struct perf_event *event, int flags) > >+{ > >+ struct hw_perf_event *hwc = &event->hw; > >+ > >+ return cvm_pmu_add(event, flags, LMC_CONFIG_OFFSET, > >+ lmc_events[hwc->config]); > >+} > >+ > > Is there any reason why we can't use the LMC event code directly > here, avoiding the mapping altogether ? I wanted to avoid exposing the raw numbers (0x1d0 - 0x368) here. thanks, Jan > >+PMU_FORMAT_ATTR(lmc_event, "config:0-2"); > >+ > >+static struct attribute *cvm_pmu_lmc_format_attr[] = { > >+ &format_attr_lmc_event.attr, > >+ NULL, > >+}; > >+ > >+static struct attribute_group cvm_pmu_lmc_format_group = { > >+ .name = "format", > >+ .attrs = cvm_pmu_lmc_format_attr, > >+}; > >+ > >+static struct attribute *cvm_pmu_lmc_events_attr[] = { > >+ CVM_PMU_LMC_EVENT_ATTR(ifb_cnt, 0), > >+ CVM_PMU_LMC_EVENT_ATTR(ops_cnt, 1), > >+ CVM_PMU_LMC_EVENT_ATTR(dclk_cnt, 2), > >+ CVM_PMU_LMC_EVENT_ATTR(bank_conflict1, 3), > >+ CVM_PMU_LMC_EVENT_ATTR(bank_conflict2, 4), > >+ NULL, > >+};