All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Garry <john.garry@huawei.com>
To: Jiri Olsa <jolsa@redhat.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 12:00:27 +0100	[thread overview]
Message-ID: <edfabc52-4b09-be92-7c40-fb2ddfe80596@huawei.com> (raw)
In-Reply-To: <YGXPdEAecos4iPVc@krava>

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 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
> 
> .
> 


WARNING: multiple messages have this Message-ID (diff)
From: John Garry <john.garry@huawei.com>
To: Jiri Olsa <jolsa@redhat.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 12:00:27 +0100	[thread overview]
Message-ID: <edfabc52-4b09-be92-7c40-fb2ddfe80596@huawei.com> (raw)
In-Reply-To: <YGXPdEAecos4iPVc@krava>

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 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

  reply	other threads:[~2021-04-06 11:03 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 [this message]
2021-04-06 11:00       ` John Garry
2021-04-06 12:17       ` Jiri Olsa
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=edfabc52-4b09-be92-7c40-fb2ddfe80596@huawei.com \
    --to=john.garry@huawei.com \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=irogers@google.com \
    --cc=jolsa@redhat.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.