All of lore.kernel.org
 help / color / mirror / Atom feed
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 15:34:16 +0200	[thread overview]
Message-ID: <YGxjWNdZGqWqL87r@krava> (raw)
In-Reply-To: <49025439-f9e3-0d32-b0a3-ff9f9ff71835@huawei.com>

On Tue, Apr 06, 2021 at 02:21:11PM +0100, John Garry wrote:
> On 06/04/2021 13:55, Jiri Olsa wrote:
> > > > > 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
> > > Sure, but we will restart anyway.
> > hum, where? you call expr__find_other and continue to next
> > pctx->ids item
> 
> We have:
> 
> resolve_metric_simple()
> {
> 	bool all;
> 
> 	do {
> 		all = true;
> 
> 		hashmap__for_each_entry_safe(&pctx->ids, ...) {
> 
> 			pe = metricgroup_find_metric(cur->key, map);
> 			if (!pe)
> 				continue;
> 
> 			...
> 			all = false;
> 
> 			expr_del_id(pctx, cur->key);
> 
> 			...
> 			rc = expr__find_other(pe->metric_expr, pctx);
> 			if (rc)
> 				goto out_err;
> 		}
> 
> 	} while (!all);
> 
> }
> 
> So once we evaluate a pmu_event in pctx->ids in @pe, @all is set false, and
> we would loop again in the do-while loop, regardless of what
> expr__find_other() does (apart from erroring), and so call
> hashmap__for_each_entry_safe(&pctx->ids, ) again.

ah ok, so it finishes the hash iteration first and
then restarts it.. ok, I missed that, then it's fine

> 
> This is really what is done in __resolve_metric() - indeed, I would use that
> function directly, but it looks hard to extract that from metricgroup.c .

yea, it's another world ;-) it's better to keep it separated

thanks,
jirka

> 
> Thanks,
> John
> 
> > 
> > > Regardless of this, I don't think what I am doing is safe, i.e. adding new
> > > items in the middle of the iter, so I will change in the way you suggest.
> > it'll always add items in the middle of the iteration
> 


_______________________________________________
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 15:34:16 +0200	[thread overview]
Message-ID: <YGxjWNdZGqWqL87r@krava> (raw)
In-Reply-To: <49025439-f9e3-0d32-b0a3-ff9f9ff71835@huawei.com>

On Tue, Apr 06, 2021 at 02:21:11PM +0100, John Garry wrote:
> On 06/04/2021 13:55, Jiri Olsa wrote:
> > > > > 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
> > > Sure, but we will restart anyway.
> > hum, where? you call expr__find_other and continue to next
> > pctx->ids item
> 
> We have:
> 
> resolve_metric_simple()
> {
> 	bool all;
> 
> 	do {
> 		all = true;
> 
> 		hashmap__for_each_entry_safe(&pctx->ids, ...) {
> 
> 			pe = metricgroup_find_metric(cur->key, map);
> 			if (!pe)
> 				continue;
> 
> 			...
> 			all = false;
> 
> 			expr_del_id(pctx, cur->key);
> 
> 			...
> 			rc = expr__find_other(pe->metric_expr, pctx);
> 			if (rc)
> 				goto out_err;
> 		}
> 
> 	} while (!all);
> 
> }
> 
> So once we evaluate a pmu_event in pctx->ids in @pe, @all is set false, and
> we would loop again in the do-while loop, regardless of what
> expr__find_other() does (apart from erroring), and so call
> hashmap__for_each_entry_safe(&pctx->ids, ) again.

ah ok, so it finishes the hash iteration first and
then restarts it.. ok, I missed that, then it's fine

> 
> This is really what is done in __resolve_metric() - indeed, I would use that
> function directly, but it looks hard to extract that from metricgroup.c .

yea, it's another world ;-) it's better to keep it separated

thanks,
jirka

> 
> Thanks,
> John
> 
> > 
> > > Regardless of this, I don't think what I am doing is safe, i.e. adding new
> > > items in the middle of the iter, so I will change in the way you suggest.
> > it'll always add items in the middle of the iteration
> 


  reply	other threads:[~2021-04-06 13:36 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
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 [this message]
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=YGxjWNdZGqWqL87r@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.