From: Jiri Olsa <jolsa@redhat.com>
To: John Garry <john.garry@huawei.com>
Cc: will@kernel.org, mathieu.poirier@linaro.org, leo.yan@linaro.org,
peterz@infradead.org, mingo@redhat.com, acme@kernel.org,
mark.rutland@arm.com, alexander.shishkin@linux.intel.com,
namhyung@kernel.org, irogers@google.com, linuxarm@huawei.com,
kjain@linux.ibm.com, kan.liang@linux.intel.com,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, zhangshaokun@hisilicon.com,
pc@us.ibm.com
Subject: Re: [PATCH v2 2/6] perf test: Handle metric reuse in pmu-events parsing test
Date: Tue, 6 Apr 2021 14:17:48 +0200 [thread overview]
Message-ID: <YGxRbH0XWaj6AWfa@krava> (raw)
In-Reply-To: <edfabc52-4b09-be92-7c40-fb2ddfe80596@huawei.com>
On Tue, Apr 06, 2021 at 12:00:27PM +0100, John Garry wrote:
> On 01/04/2021 14:49, Jiri Olsa wrote:
> > On Thu, Mar 25, 2021 at 06:33:14PM +0800, John Garry wrote:
> >
> > SNIP
> >
> > > +struct metric {
> > > + struct list_head list;
> > > + struct metric_ref metric_ref;
> > > +};
> > > +
> > > +static int resolve_metric_simple(struct expr_parse_ctx *pctx,
> > > + struct list_head *compound_list,
> > > + struct pmu_events_map *map,
> > > + const char *metric_name)
> > > +{
> > > + struct hashmap_entry *cur, *cur_tmp;
> > > + struct metric *metric, *tmp;
> > > + size_t bkt;
> > > + bool all;
> > > + int rc;
> > > +
> > > + do {
> > > + all = true;
> > > + hashmap__for_each_entry_safe((&pctx->ids), cur, cur_tmp, bkt) {
> > > + struct metric_ref *ref;
> > > + struct pmu_event *pe;
> > > +
> > > + pe = metrcgroup_find_metric(cur->key, map);
>
> *
>
> > > + if (!pe)
> > > + continue;
> > > +
> > > + if (!strcmp(metric_name, (char *)cur->key)) {
> > > + pr_warning("Recursion detected for metric %s\n", metric_name);
> > > + rc = -1;
> > > + goto out_err;
> > > + }
> > > +
> > > + all = false;
> > > +
> > > + /* The metric key itself needs to go out.. */
> > > + expr__del_id(pctx, cur->key);
> > > +
> > > + metric = malloc(sizeof(*metric));
> > > + if (!metric) {
> > > + rc = -ENOMEM;
> > > + goto out_err;
> > > + }
> > > +
> > > + ref = &metric->metric_ref;
> > > + ref->metric_name = pe->metric_name;
> > > + ref->metric_expr = pe->metric_expr;
> > > + list_add_tail(&metric->list, compound_list);
> > > +
> > > + rc = expr__find_other(pe->metric_expr, NULL, pctx, 0);
> >
>
> Hi Jirka,
>
> > so this might add new items to pctx->ids, I think you need
> > to restart the iteration as we do it in __resolve_metric
> > otherwise you could miss some new keys
>
> I thought that I was doing this. Indeed, this code is very much like
> __resolve_metric() ;)
>
> So expr__find_other() may add a new item to pctx->ids, and we always iterate
> again, and try to lookup any pmu_events, *, above. If none exist, then we
hm, I don't see that.. so, what you do is:
hashmap__for_each_entry_safe((&pctx->ids) ....) {
rc = expr__find_other(pe->metric_expr, NULL, pctx, 0);
}
and what I think we need to do is:
hashmap__for_each_entry_safe((&pctx->ids) ....) {
rc = expr__find_other(pe->metric_expr, NULL, pctx, 0);
break;
}
each time you resolve another metric, you need to restart
the pctx->ids iteration, because there will be new items,
and we are in the middle of it
jirka
> have broken down pctx into primitive events aliases and unresolvable
> metrics, and stop iterating. And then unresolvable metrics would be found in
> check_parse_cpu().
>
> As an example, we can deal with metric test1, below, which references 2x
> other metrics:
>
> {
> "MetricExpr": "IDQ_UOPS_NOT_DELIVERED.CORE / (4 * (( (
> CPU_CLK_UNHALTED.THREAD / 2 ) * ( 1 + CPU_CLK_UNHALTED.ONE_THREAD_ACTIVE /
> CPU_CLK_UNHALTED.REF_XCLK ) )))",
> "MetricName": "Frontend_Bound",
> },
> {
> "MetricExpr": "( UOPS_ISSUED.ANY - UOPS_RETIRED.RETIRE_SLOTS + 4 *
> INT_MISC.RECOVERY_CYCLES ) / (4 * cycles)",
> "MetricName": "Bad_Speculation",
> },
> {
> "MetricExpr": "Bad_Speculation + Frontend_Bound",
> "MetricName": "test1",
> },
>
> Does that satisfy your concern, or have I missed something?
>
> Thanks,
> John
>
> >
> > jirka
> >
> > > + if (rc)
> > > + goto out_err;
> > > + }
> > > + } while (!all);
> > > +
> > > + return 0;
> > > +
> > > +out_err:
> > > + list_for_each_entry_safe(metric, tmp, compound_list, list)
> > > + free(metric);
> > > +
> > > + return rc;
> > > +
> > > +}
> >
> > SNIP
> >
> > .
> >
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Jiri Olsa <jolsa@redhat.com>
To: John Garry <john.garry@huawei.com>
Cc: will@kernel.org, mathieu.poirier@linaro.org, leo.yan@linaro.org,
peterz@infradead.org, mingo@redhat.com, acme@kernel.org,
mark.rutland@arm.com, alexander.shishkin@linux.intel.com,
namhyung@kernel.org, irogers@google.com, linuxarm@huawei.com,
kjain@linux.ibm.com, kan.liang@linux.intel.com,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, zhangshaokun@hisilicon.com,
pc@us.ibm.com
Subject: Re: [PATCH v2 2/6] perf test: Handle metric reuse in pmu-events parsing test
Date: Tue, 6 Apr 2021 14:17:48 +0200 [thread overview]
Message-ID: <YGxRbH0XWaj6AWfa@krava> (raw)
In-Reply-To: <edfabc52-4b09-be92-7c40-fb2ddfe80596@huawei.com>
On Tue, Apr 06, 2021 at 12:00:27PM +0100, John Garry wrote:
> On 01/04/2021 14:49, Jiri Olsa wrote:
> > On Thu, Mar 25, 2021 at 06:33:14PM +0800, John Garry wrote:
> >
> > SNIP
> >
> > > +struct metric {
> > > + struct list_head list;
> > > + struct metric_ref metric_ref;
> > > +};
> > > +
> > > +static int resolve_metric_simple(struct expr_parse_ctx *pctx,
> > > + struct list_head *compound_list,
> > > + struct pmu_events_map *map,
> > > + const char *metric_name)
> > > +{
> > > + struct hashmap_entry *cur, *cur_tmp;
> > > + struct metric *metric, *tmp;
> > > + size_t bkt;
> > > + bool all;
> > > + int rc;
> > > +
> > > + do {
> > > + all = true;
> > > + hashmap__for_each_entry_safe((&pctx->ids), cur, cur_tmp, bkt) {
> > > + struct metric_ref *ref;
> > > + struct pmu_event *pe;
> > > +
> > > + pe = metrcgroup_find_metric(cur->key, map);
>
> *
>
> > > + if (!pe)
> > > + continue;
> > > +
> > > + if (!strcmp(metric_name, (char *)cur->key)) {
> > > + pr_warning("Recursion detected for metric %s\n", metric_name);
> > > + rc = -1;
> > > + goto out_err;
> > > + }
> > > +
> > > + all = false;
> > > +
> > > + /* The metric key itself needs to go out.. */
> > > + expr__del_id(pctx, cur->key);
> > > +
> > > + metric = malloc(sizeof(*metric));
> > > + if (!metric) {
> > > + rc = -ENOMEM;
> > > + goto out_err;
> > > + }
> > > +
> > > + ref = &metric->metric_ref;
> > > + ref->metric_name = pe->metric_name;
> > > + ref->metric_expr = pe->metric_expr;
> > > + list_add_tail(&metric->list, compound_list);
> > > +
> > > + rc = expr__find_other(pe->metric_expr, NULL, pctx, 0);
> >
>
> Hi Jirka,
>
> > so this might add new items to pctx->ids, I think you need
> > to restart the iteration as we do it in __resolve_metric
> > otherwise you could miss some new keys
>
> I thought that I was doing this. Indeed, this code is very much like
> __resolve_metric() ;)
>
> So expr__find_other() may add a new item to pctx->ids, and we always iterate
> again, and try to lookup any pmu_events, *, above. If none exist, then we
hm, I don't see that.. so, what you do is:
hashmap__for_each_entry_safe((&pctx->ids) ....) {
rc = expr__find_other(pe->metric_expr, NULL, pctx, 0);
}
and what I think we need to do is:
hashmap__for_each_entry_safe((&pctx->ids) ....) {
rc = expr__find_other(pe->metric_expr, NULL, pctx, 0);
break;
}
each time you resolve another metric, you need to restart
the pctx->ids iteration, because there will be new items,
and we are in the middle of it
jirka
> have broken down pctx into primitive events aliases and unresolvable
> metrics, and stop iterating. And then unresolvable metrics would be found in
> check_parse_cpu().
>
> As an example, we can deal with metric test1, below, which references 2x
> other metrics:
>
> {
> "MetricExpr": "IDQ_UOPS_NOT_DELIVERED.CORE / (4 * (( (
> CPU_CLK_UNHALTED.THREAD / 2 ) * ( 1 + CPU_CLK_UNHALTED.ONE_THREAD_ACTIVE /
> CPU_CLK_UNHALTED.REF_XCLK ) )))",
> "MetricName": "Frontend_Bound",
> },
> {
> "MetricExpr": "( UOPS_ISSUED.ANY - UOPS_RETIRED.RETIRE_SLOTS + 4 *
> INT_MISC.RECOVERY_CYCLES ) / (4 * cycles)",
> "MetricName": "Bad_Speculation",
> },
> {
> "MetricExpr": "Bad_Speculation + Frontend_Bound",
> "MetricName": "test1",
> },
>
> Does that satisfy your concern, or have I missed something?
>
> Thanks,
> John
>
> >
> > jirka
> >
> > > + if (rc)
> > > + goto out_err;
> > > + }
> > > + } while (!all);
> > > +
> > > + return 0;
> > > +
> > > +out_err:
> > > + list_for_each_entry_safe(metric, tmp, compound_list, list)
> > > + free(metric);
> > > +
> > > + return rc;
> > > +
> > > +}
> >
> > SNIP
> >
> > .
> >
>
next prev parent reply other threads:[~2021-04-06 12:19 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-25 10:33 [PATCH v2 0/6] perf arm64 metricgroup support John Garry
2021-03-25 10:33 ` John Garry
2021-03-25 10:33 ` [PATCH v2 1/6] perf metricgroup: Make find_metric() public with name change John Garry
2021-03-25 10:33 ` John Garry
2021-04-01 23:16 ` Ian Rogers
2021-04-01 23:16 ` Ian Rogers
2021-04-06 9:54 ` John Garry
2021-04-06 9:54 ` John Garry
2021-04-07 5:39 ` kajoljain
2021-04-07 5:39 ` kajoljain
2021-03-25 10:33 ` [PATCH v2 2/6] perf test: Handle metric reuse in pmu-events parsing test John Garry
2021-03-25 10:33 ` John Garry
2021-04-01 13:49 ` Jiri Olsa
2021-04-01 13:49 ` Jiri Olsa
2021-04-06 11:00 ` John Garry
2021-04-06 11:00 ` John Garry
2021-04-06 12:17 ` Jiri Olsa [this message]
2021-04-06 12:17 ` Jiri Olsa
2021-04-06 12:43 ` John Garry
2021-04-06 12:43 ` John Garry
2021-04-06 12:55 ` Jiri Olsa
2021-04-06 12:55 ` Jiri Olsa
2021-04-06 13:21 ` John Garry
2021-04-06 13:21 ` John Garry
2021-04-06 13:34 ` Jiri Olsa
2021-04-06 13:34 ` Jiri Olsa
2021-04-06 13:38 ` John Garry
2021-04-06 13:38 ` John Garry
2021-03-25 10:33 ` [PATCH v2 3/6] perf pmu: Add pmu_events_map__find() John Garry
2021-03-25 10:33 ` John Garry
2021-03-25 10:33 ` [PATCH v2 4/6] perf vendor events arm64: Add Hisi hip08 L1 metrics John Garry
2021-03-25 10:33 ` John Garry
2021-03-25 10:33 ` [PATCH v2 5/6] perf vendor events arm64: Add Hisi hip08 L2 metrics John Garry
2021-03-25 10:33 ` John Garry
2021-03-25 10:33 ` [PATCH v2 6/6] perf vendor events arm64: Add Hisi hip08 L3 metrics John Garry
2021-03-25 10:33 ` John Garry
2021-03-25 20:39 ` [PATCH v2 0/6] perf arm64 metricgroup support Paul A. Clarke
2021-03-25 20:39 ` Paul A. Clarke
2021-03-26 10:57 ` John Garry
2021-03-26 10:57 ` John Garry
2021-03-26 13:13 ` Paul A. Clarke
2021-03-26 13:13 ` Paul A. Clarke
2021-03-29 21:07 ` Paul A. Clarke
2021-03-29 21:07 ` Paul A. Clarke
2021-03-30 6:41 ` kajoljain
2021-03-30 6:41 ` kajoljain
2021-04-06 11:02 ` John Garry
2021-04-06 11:02 ` John Garry
2021-04-06 12:18 ` Paul A. Clarke
2021-04-06 12:18 ` Paul A. Clarke
2021-04-07 6:03 ` kajoljain
2021-04-07 6:03 ` 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=YGxRbH0XWaj6AWfa@krava \
--to=jolsa@redhat.com \
--cc=acme@kernel.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=irogers@google.com \
--cc=john.garry@huawei.com \
--cc=kan.liang@linux.intel.com \
--cc=kjain@linux.ibm.com \
--cc=leo.yan@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=mark.rutland@arm.com \
--cc=mathieu.poirier@linaro.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=pc@us.ibm.com \
--cc=peterz@infradead.org \
--cc=will@kernel.org \
--cc=zhangshaokun@hisilicon.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.