[PATCH V1 3/4] perf vendor events: Add JSON metrics for imx8mq DDR Perf

[Joakim Zhang]

> -----Original Message-----
> From: John Garry <john.garry at huawei.com>
> Sent: 2021年1月20日 17:26
> To: Joakim Zhang <qiangqing.zhang at nxp.com>; acme at kernel.org;
> jolsa at redhat.com
> Cc: will at kernel.org; linux-perf-users at vger.kernel.org; dl-linux-imx
> <linux-imx at nxp.com>; mark.rutland at arm.com;
> linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH V1 3/4] perf vendor events: Add JSON metrics for imx8mq
> DDR Perf
> 
> On 20/01/2021 05:46, Joakim Zhang wrote:
> >> -----Original Message-----
> >> From: John Garry<john.garry at huawei.com>
> >> Sent: 2021年1月19日 20:27
> >> To: Joakim Zhang<qiangqing.zhang at nxp.com>;acme at kernel.org;
> >> jolsa at redhat.com
> >> Cc:will at kernel.org;linux-perf-users at vger.kernel.org; dl-linux-imx
> >> <linux-imx at nxp.com>;mark.rutland at arm.com;
> >> linux-arm-kernel at lists.infradead.org
> >> Subject: Re: [PATCH V1 3/4] perf vendor events: Add JSON metrics for
> >> imx8mq DDR Perf
> >>
> >> On 19/01/2021 11:00, Joakim Zhang wrote:
> >>>> -----Original Message-----
> >>>> From: John Garry<john.garry at huawei.com>
> >>>> Sent: 2021年1月19日 18:40
> >>>> To: Joakim Zhang<qiangqing.zhang at nxp.com>;acme at kernel.org;
> >>>> jolsa at redhat.com
> >>>> Cc:will at kernel.org;linux-perf-users at vger.kernel.org; dl-linux-imx
> >>>> <linux-imx at nxp.com>;mark.rutland at arm.com;
> >>>> linux-arm-kernel at lists.infradead.org
> >>>> Subject: Re: [PATCH V1 3/4] perf vendor events: Add JSON metrics
> >>>> for imx8mq DDR Perf
> >>>>
> >>>> On 19/01/2021 02:56, Joakim Zhang wrote:
> >>>>> index 000000000000..c3e9f89a4a4d
> >>>>> --- /dev/null
> >>>>> +++
> b/tools/perf/pmu-events/arch/arm64/freescale/imx8mq/sys/metrics.
> >>>>> +++ js
> >>>>> +++ on
> >>>>> @@ -0,0 +1,26 @@
> >>>>> +[
> >>>>> +   {
> >>>>> +	    "BriefDescription": "bandwidth usage for lpddr4 evk board",
> >>>> Why mention the evk board specifically? Is this metric only
> >>>> specific to that board, and not all i.MX8MQ platforms?
> >>> Yes, John, we have lpddr4 evk board and ddr4 evk borad......
> >>>
> >> How is this supposed to work?
> >>
> >> So perf matches on the identifier file for system PMUs; however the
> >> contents of this file are based on the HW implementation for imx DDR PMU,
> not the board.
> > Yes, I know this feature is for system PMU, not board. You know DDR
> bandwidth calculation is based on DDR clock frequency, which is vary form
> boards.
> >
> > e.g.
> > lpddr4 board, DDR clock frequency is 750MHZ:
> > "MetricExpr": "(( imx8_ddr0 at read\\-cycles@ + imx8_ddr0 at write\\-cycles@ )
> * 4 * 4 / duration_time) / (750 * 1000000 * 4 * 4)"
> >
> > ddr4 board, DDR clock frequency is 600MHZ.
> > "MetricExpr": "(( imx8_ddr0 at read\\-cycles@ + imx8_ddr0 at write\\-cycles@ )
> * 4 * 4 / duration_time) / (600 * 1000000 * 4 * 4)"
> >
> > I give different metric names,
> > "MetricName": "imx8mm_bandwidth_usage.lpddr4"
> > "MetricName": "imx8mm_bandwidth_usage.ddr4"
> >
> 
> But that is just not how things are done. We - or I - would expect that perf tool
> would have the intelligence to know the appropriate metric for that specific
> platform. Or, more specifically, we should not present the user with many
> metrics and expect him/her to know the appropriate metric for the specific
> board.
> 
> Are there other cases for other architectures where things are done like this?


I don't know if exist other cases. If you can’t accept it, I can only push part of it first, and let bandwidth metric locally.


Best Regards,
Joakim Zhang
> Thanks,
> John
> 
> > So users can select correct bandwidth metric according to their own board
> types. To a certain extent, it can also support some board-level metrics.
> >
> > If it is okay for you, I will send a V2 to replace ( imx8_ddr0 at read\\-cycles@ +
> imx8_ddr0 at write\\-cycles@ ) with ( imx8mm_ddr.read_cycles +
> imx8mm_ddr.write_cycles ).
> >
> >>> John, change to your new framework, I found it can't support all
> >>> features
> >> which is supported in 5.10 kernel.
> >>
> >> Yes, so let me know about all the problems.
> > It should have worked as 5.10 kernel at my side. Thanks.