All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Rogers <irogers@google.com>
To: Andi Kleen <ak@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@redhat.com>, Namhyung Kim <namhyung@kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Martin KaFai Lau <kafai@fb.com>, Song Liu <songliubraving@fb.com>,
	Yonghong Song <yhs@fb.com>, Andrii Nakryiko <andriin@fb.com>,
	John Fastabend <john.fastabend@gmail.com>,
	KP Singh <kpsingh@chromium.org>, Kajol Jain <kjain@linux.ibm.com>,
	John Garry <john.garry@huawei.com>,
	Jin Yao <yao.jin@linux.intel.com>,
	Kan Liang <kan.liang@linux.intel.com>,
	Cong Wang <xiyou.wangcong@gmail.com>,
	Kim Phillips <kim.phillips@amd.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Networking <netdev@vger.kernel.org>, bpf <bpf@vger.kernel.org>,
	linux-perf-users <linux-perf-users@vger.kernel.org>,
	Vince Weaver <vincent.weaver@maine.edu>,
	Stephane Eranian <eranian@google.com>
Subject: Re: [RFC PATCH v3 12/14] perf metricgroup: order event groups by size
Date: Wed, 20 May 2020 00:46:22 -0700	[thread overview]
Message-ID: <CAP-5=fVPh0og6CmjM4G1bDGB_S+Sp4v_4WM3r5XqwQPbk7ASdg@mail.gmail.com> (raw)
In-Reply-To: <20200509024019.GI3538@tassilo.jf.intel.com>

On Fri, May 8, 2020 at 7:40 PM Andi Kleen <ak@linux.intel.com> wrote:
>
> > > I'm not sure if size is that great an heuristic. The dedup algorithm should
> > > work in any case even if you don't order by size, right?
> >
> > Consider two metrics:
> >  - metric 1 with events {A,B}
> >  - metric 2 with events {A,B,C,D}
> > If the list isn't sorted then as the matching takes the first group
> > with all the events, metric 1 will match {A,B} and metric 2 {A,B,C,D}.
> > If the order is sorted to {A,B,C,D},{A,B} then metric 1 matches within
> > the {A,B,C,D} group as does metric 2. The events in metric 1 aren't
> > used and are removed.
>
> Ok. It's better for the longer metric if they stay together.
>
> >
> > The dedup algorithm is very naive :-)
>
> I guess what matters is that it gives reasonable results on the current
> metrics. I assume it does?
>
> How much deduping is happening if you run all metrics?

Hi Andi,

I included this data in the latest cover-letter:
https://lore.kernel.org/lkml/20200520072814.128267-1-irogers@google.com/

> For toplev on my long term todo list was to compare it against
> a hopefully better schedule generated by or-tools, but I never
> got around to coding that up.
>
> -Andi

Agreed, and this relates to your comments about doing the algorithm as
a separate pass outside of find_evsel_group. For that, I don't
disagree but would like to land what we have and then follow up with
improvements.

Thanks,
Ian

WARNING: multiple messages have this Message-ID (diff)
From: Ian Rogers <irogers@google.com>
To: Andi Kleen <ak@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@redhat.com>, Namhyung Kim <namhyung@kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Martin KaFai Lau <kafai@fb.com>, Song Liu <songliubraving@fb.com>,
	Yonghong Song <yhs@fb.com>, Andrii Nakryiko <andriin@fb.com>,
	John Fastabend <john.fastabend@gmail.com>,
	KP Singh <kpsingh@chromium.org>, Kajol Jain <kjain@linux.ibm.com>,
	John Garry <john.garry@huawei.com>,
	Jin Yao <yao.jin@linux.intel.com>,
	Kan Liang <kan.liang@linux.intel.com>,
	Cong Wang <xiyou.wangcong@gmail.com>Kim
Subject: Re: [RFC PATCH v3 12/14] perf metricgroup: order event groups by size
Date: Wed, 20 May 2020 00:46:22 -0700	[thread overview]
Message-ID: <CAP-5=fVPh0og6CmjM4G1bDGB_S+Sp4v_4WM3r5XqwQPbk7ASdg@mail.gmail.com> (raw)
In-Reply-To: <20200509024019.GI3538@tassilo.jf.intel.com>

On Fri, May 8, 2020 at 7:40 PM Andi Kleen <ak@linux.intel.com> wrote:
>
> > > I'm not sure if size is that great an heuristic. The dedup algorithm should
> > > work in any case even if you don't order by size, right?
> >
> > Consider two metrics:
> >  - metric 1 with events {A,B}
> >  - metric 2 with events {A,B,C,D}
> > If the list isn't sorted then as the matching takes the first group
> > with all the events, metric 1 will match {A,B} and metric 2 {A,B,C,D}.
> > If the order is sorted to {A,B,C,D},{A,B} then metric 1 matches within
> > the {A,B,C,D} group as does metric 2. The events in metric 1 aren't
> > used and are removed.
>
> Ok. It's better for the longer metric if they stay together.
>
> >
> > The dedup algorithm is very naive :-)
>
> I guess what matters is that it gives reasonable results on the current
> metrics. I assume it does?
>
> How much deduping is happening if you run all metrics?

Hi Andi,

I included this data in the latest cover-letter:
https://lore.kernel.org/lkml/20200520072814.128267-1-irogers@google.com/

> For toplev on my long term todo list was to compare it against
> a hopefully better schedule generated by or-tools, but I never
> got around to coding that up.
>
> -Andi

Agreed, and this relates to your comments about doing the algorithm as
a separate pass outside of find_evsel_group. For that, I don't
disagree but would like to land what we have and then follow up with
improvements.

Thanks,
Ian

  reply	other threads:[~2020-05-20  7:53 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-08  5:36 [RFC PATCH v3 00/14] Share events between metrics Ian Rogers
2020-05-08  5:36 ` Ian Rogers
2020-05-08  5:36 ` [RFC PATCH v3 01/14] perf parse-events: expand add PMU error/verbose messages Ian Rogers
2020-05-08  5:36   ` Ian Rogers
2020-05-09  0:14   ` Andi Kleen
2020-05-09  0:14     ` Andi Kleen
2020-05-08  5:36 ` [RFC PATCH v3 02/14] perf test: improve pmu event metric testing Ian Rogers
2020-05-08  5:36   ` Ian Rogers
2020-05-08  5:36 ` [RFC PATCH v3 03/14] lib/bpf hashmap: increase portability Ian Rogers
2020-05-08  5:36   ` Ian Rogers
2020-05-08  5:36 ` [RFC PATCH v3 04/14] libbpf: Fix memory leak and possible double-free in hashmap__clear Ian Rogers
2020-05-08  5:36   ` Ian Rogers
2020-05-08  5:36 ` [RFC PATCH v3 05/14] perf expr: fix memory leaks in bison Ian Rogers
2020-05-08  5:36   ` Ian Rogers
2020-05-08  5:36 ` [RFC PATCH v3 06/14] perf evsel: fix 2 memory leaks Ian Rogers
2020-05-08  5:36   ` Ian Rogers
2020-05-09  0:39   ` Andi Kleen
2020-05-09  0:39     ` Andi Kleen
2020-05-09  0:41     ` Ian Rogers
2020-05-09  0:41       ` Ian Rogers
2020-05-08  5:36 ` [RFC PATCH v3 07/14] perf expr: migrate expr ids table to libbpf's hashmap Ian Rogers
2020-05-08  5:36   ` Ian Rogers
2020-05-08  5:36 ` [RFC PATCH v3 08/14] perf metricgroup: change evlist_used to a bitmap Ian Rogers
2020-05-08  5:36   ` Ian Rogers
2020-05-08  5:36 ` [RFC PATCH v3 09/14] perf metricgroup: free metric_events on error Ian Rogers
2020-05-08  5:36   ` Ian Rogers
2020-05-21 17:07   ` Arnaldo Carvalho de Melo
2020-05-21 17:07     ` Arnaldo Carvalho de Melo
2020-05-08  5:36 ` [RFC PATCH v3 10/14] perf metricgroup: always place duration_time last Ian Rogers
2020-05-08  5:36   ` Ian Rogers
2020-05-08  5:36 ` [RFC PATCH v3 11/14] perf metricgroup: delay events string creation Ian Rogers
2020-05-08  5:36   ` Ian Rogers
2020-05-08  5:36 ` [RFC PATCH v3 12/14] perf metricgroup: order event groups by size Ian Rogers
2020-05-08  5:36   ` Ian Rogers
2020-05-09  0:25   ` Andi Kleen
2020-05-09  0:25     ` Andi Kleen
2020-05-09  0:40     ` Ian Rogers
2020-05-09  0:40       ` Ian Rogers
2020-05-09  2:40       ` Andi Kleen
2020-05-09  2:40         ` Andi Kleen
2020-05-20  7:46         ` Ian Rogers [this message]
2020-05-20  7:46           ` Ian Rogers
2020-05-08  5:36 ` [RFC PATCH v3 13/14] perf metricgroup: remove duped metric group events Ian Rogers
2020-05-08  5:36   ` Ian Rogers
2020-05-09  0:38   ` Andi Kleen
2020-05-09  0:38     ` Andi Kleen
2020-05-08  5:36 ` [RFC PATCH v3 14/14] perf metricgroup: add options to not group or merge Ian Rogers
2020-05-08  5:36   ` Ian Rogers
2020-05-09  0:12 ` [RFC PATCH v3 00/14] Share events between metrics Andi Kleen
2020-05-09  0:12   ` Andi Kleen

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='CAP-5=fVPh0og6CmjM4G1bDGB_S+Sp4v_4WM3r5XqwQPbk7ASdg@mail.gmail.com' \
    --to=irogers@google.com \
    --cc=acme@kernel.org \
    --cc=ak@linux.intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=andriin@fb.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eranian@google.com \
    --cc=john.fastabend@gmail.com \
    --cc=john.garry@huawei.com \
    --cc=jolsa@redhat.com \
    --cc=kafai@fb.com \
    --cc=kan.liang@linux.intel.com \
    --cc=kim.phillips@amd.com \
    --cc=kjain@linux.ibm.com \
    --cc=kpsingh@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=songliubraving@fb.com \
    --cc=vincent.weaver@maine.edu \
    --cc=xiyou.wangcong@gmail.com \
    --cc=yao.jin@linux.intel.com \
    --cc=yhs@fb.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.