From: kajoljain <kjain@linux.ibm.com>
To: Joakim Zhang <qiangqing.zhang@nxp.com>,
"acme@kernel.org" <acme@kernel.org>, Jiri Olsa <jolsa@kernel.org>,
Andi Kleen <ak@linux.intel.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-perf-users@vger.kernel.org"
<linux-perf-users@vger.kernel.org>,
Kan Liang <kan.liang@linux.intel.com>,
Madhavan Srinivasan <maddy@linux.vnet.ibm.com>,
Anju T Sudhakar <anju@linux.vnet.ibm.com>,
Ravi Bangoria <ravi.bangoria@linux.ibm.com>
Subject: [RFC] Issue in final aggregate value, in case of multiple events present in metric expression
Date: Tue, 24 Mar 2020 13:30:45 +0530 [thread overview]
Message-ID: <6f98d281-f3de-b547-70d4-8fc95515b12f@linux.ibm.com> (raw)
In-Reply-To: <DB7PR04MB4618D0696D39AC5D44FF5A51E6F50@DB7PR04MB4618.eurprd04.prod.outlook.com>
Hello All,
I want to discuss one issue raised by Joakim Zhang where he mentioned
that, we are not getting correct result in-case of multiple events present in metric
expression.
This is one example pointed by him :
below is the JSON file and result.
[
{
"PublicDescription": "Calculate DDR0 bus actual utilization which vary from DDR0 controller clock frequency",
"BriefDescription": "imx8qm: ddr0 bus actual utilization",
"MetricName": "imx8qm-ddr0-bus-util",
"MetricExpr": "( imx8_ddr0\\/read\\-cycles\\/ + imx8_ddr0\\/write\\-cycles\\/ )",
"MetricGroup": "i.MX8QM_DDR0_BUS_UTIL"
}
]
./perf stat -I 1000 -M imx8qm-ddr0-bus-util
# time counts unit events
1.000104250 16720 imx8_ddr0/read-cycles/ # 22921.0 imx8qm-ddr0-bus-util
1.000104250 6201 imx8_ddr0/write-cycles/
2.000525625 8316 imx8_ddr0/read-cycles/ # 12785.5 imx8qm-ddr0-bus-util
2.000525625 2738 imx8_ddr0/write-cycles/
3.000819125 1056 imx8_ddr0/read-cycles/ # 4136.7 imx8qm-ddr0-bus-util
3.000819125 303 imx8_ddr0/write-cycles/
4.001103750 6260 imx8_ddr0/read-cycles/ # 9149.8 imx8qm-ddr0-bus-util
4.001103750 2317 imx8_ddr0/write-cycles/
5.001392750 2084 imx8_ddr0/read-cycles/ # 4516.0 imx8qm-ddr0-bus-util
5.001392750 601 imx8_ddr0/write-cycles/
Based on given metric expression, the sum coming correct for first iteration while for
rest, we won't see same addition result. But in-case we have single event in metric
expression, we are getting correct result as expected.
So, I try to look into this issue and understand the flow. From my understanding, whenever we do
calculation of metric expression we don't use exact count we are getting.
Basically we use mean value of each metric event in the calculation of metric expression.
So, I take same example:
Metric Event: imx8qm-ddr0-bus-util
MetricExpr": "( imx8_ddr0\\/read\\-cycles\\/ + imx8_ddr0\\/write\\-cycles\\/ )"
command#: ./perf stat -I 1000 -M imx8qm-ddr0-bus-util
# time counts unit events
1.000104250 16720 imx8_ddr0/read-cycles/ # 22921.0 imx8qm-ddr0-bus-util
1.000104250 6201 imx8_ddr0/write-cycles/
2.000525625 8316 imx8_ddr0/read-cycles/ # 12785.5 imx8qm-ddr0-bus-util
2.000525625 2738 imx8_ddr0/write-cycles/
3.000819125 1056 imx8_ddr0/read-cycles/ # 4136.7 imx8qm-ddr0-bus-util
3.000819125 303 imx8_ddr0/write-cycles/
4.001103750 6260 imx8_ddr0/read-cycles/ # 9149.8 imx8qm-ddr0-bus-util
4.001103750 2317 imx8_ddr0/write-cycles/
5.001392750 2084 imx8_ddr0/read-cycles/ # 4516.0 imx8qm-ddr0-bus-util
5.001392750 601 imx8_ddr0/write-cycles/
So, there is one function called 'update_stats' in file util/stat.c where we do this calculation
and updating stats->mean value. And this mean value is what we are actually using in our
metric expression calculation.
We call this function in each iteration where we update stats->mean and stats->n for each event.
But one weird issue is, for very first event, stat->n is always 1 that is why we are getting
mean same as count.
So this the reason why for single event we get exact aggregate of metric expression.
So doesn't matter how many events you have in your metric expression, every time
you take exact count for first one and normalized value for rest which is weird.
According to update_stats function: We are updating mean as:
stats->mean += delta / stats->n where, delta = val - stats->mean.
If we take write-cycles here. Initially mean = 0 and n = 1.
1st iteration: n=1, write cycle : 6201 and mean = 6201 (Final agg value: 16720 + 6201 = 22921)
2nd iteration: n=2, write cycles: 6201 + (2738 - 6201)/2 = 4469.5 (Final aggr value: 8316 + 4469.5 = 12785.5)
3rd iteration: n=3, write cycles: 4469.5 + (303 - 4469.5)/3 = 3080.6667 (Final aggr value: 1056 + 3080.6667 = 4136.7)
I am not sure if its expected behavior. I mean shouldn't we either take mean value of each event
or take n as 1 for each event.
I am thinking, Should we add an option to say whether user want exact aggregate or
this normalize aggregate to remove the confusion? I try to find it out if we already have one but didn't get.
Please let me know if my understanding is fine. Or something I can add to resolve this issue.
Thanks,
Kajol
next prev parent reply other threads:[~2020-03-24 8:00 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-12 5:41 [PATCH v4] tools/perf/metricgroup: Fix printing event names of metric group with multiple events incase of overlapping events Kajol Jain
2020-02-16 20:21 ` Jiri Olsa
2020-02-18 5:57 ` kajoljain
2020-02-17 3:11 ` Joakim Zhang
2020-02-20 9:53 ` kajoljain
2020-02-20 10:36 ` Joakim Zhang
2020-03-02 6:14 ` kajoljain
2020-03-20 6:47 ` Joakim Zhang
2020-03-24 7:13 ` kajoljain
2020-03-24 8:00 ` kajoljain [this message]
2020-05-09 5:52 ` [RFC] Issue in final aggregate value, in case of multiple events present in metric expression Joakim Zhang
2020-05-11 0:56 ` Andi Kleen
2020-05-11 1:12 ` Jin, Yao
2020-05-11 2:05 ` Joakim Zhang
2020-05-13 8:08 ` Joakim Zhang
2020-03-02 1:17 ` [tools/perf/metricgroup] 5dd4f4ab07: stderr.mv:cannot_stat'util/.metricgroup.o.tmp':No_such_file_or_directory kernel test robot
2020-03-02 5:00 ` kajoljain
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6f98d281-f3de-b547-70d4-8fc95515b12f@linux.ibm.com \
--to=kjain@linux.ibm.com \
--cc=acme@kernel.org \
--cc=ak@linux.intel.com \
--cc=anju@linux.vnet.ibm.com \
--cc=jolsa@kernel.org \
--cc=kan.liang@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=maddy@linux.vnet.ibm.com \
--cc=qiangqing.zhang@nxp.com \
--cc=ravi.bangoria@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).