BPF Archive on lore.kernel.org
 help / color / Atom feed
From: Ian Rogers <irogers@google.com>
To: Jiri Olsa <jolsa@redhat.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>,
	Namhyung Kim <namhyung@kernel.org>,
	Song Liu <songliubraving@fb.com>,
	Andrii Nakryiko <andriin@fb.com>,
	Kajol Jain <kjain@linux.ibm.com>, Andi Kleen <ak@linux.intel.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>, Paul Clarke <pc@us.ibm.com>,
	Srikar Dronamraju <srikar@linux.vnet.ibm.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: [PATCH 5/7] perf metricgroup: Remove duped metric group events
Date: Wed, 20 May 2020 15:42:02 -0700
Message-ID: <CAP-5=fU12vP45Sg3uRSuz-xoceTPTKw9-XZieKv1PaTnREMdrw@mail.gmail.com> (raw)
In-Reply-To: <20200520220912.GP157452@krava>

On Wed, May 20, 2020 at 3:09 PM Jiri Olsa <jolsa@redhat.com> wrote:
>
> On Wed, May 20, 2020 at 09:50:13AM -0700, Ian Rogers wrote:
>
> SNIP
>
> > > > +             }
> > >
> > > is the groupping still enabled when we merge groups? could part
> > > of the metric (events) be now computed in different groups?
> >
> > By default the change will take two metrics and allow the shorter
> > metric (in terms of number of events) to share the events of the
> > longer metric. If the events for the shorter metric aren't in the
> > longer metric then the shorter metric must use its own group of
> > events. If sharing has occurred then the bitmap is used to work out
> > which events and groups are no longer in use.
> >
> > With --metric-no-group then any event can be used for a metric as
> > there is no grouping. This is why more events can be eliminated.
> >
> > With --metric-no-merge then the logic to share events between
> > different metrics is disabled and every metric is in a group. This
> > allows the current behavior to be had.
> >
> > There are some corner cases, such as metrics with constraints (that
> > don't group) and duration_time that is never placed into a group.
> >
> > Partial sharing, with one event in 1 weak event group and 1 in another
> > is never performed. Using --metric-no-group allows something similar.
> > Given multiplexing, I'd be concerned about accuracy problems if events
> > between groups were shared - say for IPC, were you measuring
> > instructions and cycles at the same moment?
>
> hum, I think that's also concern if you are multiplexing 2 groups and one
> metric getting events from both groups that were not meassured together
>
> it makes sense to me put all the merged events into single weak group
> anything else will have the issue you described above, no?
>
> and perhaps add command line option for merging that to make sure it's
> what user actuly wants

I'm not sure I'm following. With the patch set if we have 3 metrics
with the event groups shown:
M1: {A,B,C}:W
M2: {A,B}:W
M3: {A,B,D}:W

then what happens is we sort the metrics in to M1, M3, M2 then when we
come to match the events:

 - by default: match events allowing sharing if all events come from
the same group. So in the example M1 will first match with {A,B,C}
then M3 will fail to match the group {A,B,C} but match {A,B,D}; M2
will succeed with matching {A,B} from M1. The events/group for M2 can
be removed as they are no longer used. This kind of sharing is
opportunistic and respects existing groupings. While it may mean a
metric is computed from a group that now multiplexes, that group will
run for more of the time as there are fewer groups to multiplex with.
In this example we've gone from 3 groups down to 2, 8 events down to
6. An improvement would be to realize that A,B is in both M1 and M3,
so when we print the stat we could combine these values.

 - with --metric-no-merge: no events are shared by metrics M1, M2 and
M3 have their events and computation as things currently are. There
are 3 groups and 8 events.

 - with --metric-no-group: all groups are removed and so the evlist
has A,B,C,A,B,A,B,D in it. The matching will now match M1 to A,B,C at
the beginning of the list, M2 to the first A,B and M3 to the same A,B
and D at the end of the list. We've got no groups and the events have
gone from 8 down to 4.

It is difficult to reason about which grouping is most accurate. If we
have 4 counters (no NMI watchdog) then this example will fit with no
multiplexing. The default above should achieve less multiplexing, in
the same way merging PMU events currently does - this patch is trying
to mirror the --no-merge functionality to a degree. Considering
TopDownL1 then we go from metrics that never sum to 100%, to metrics
that do in either the default or --metric-no-group cases.

I'm not sure what user option is missing with these combinations? The
default is trying to strike a compromise and I think user interaction
is unnecessary, just as --no-merge doesn't cause interaction. If the
existing behavior is wanted using --metric-no-merge will give that.
The new default and --metric-no-group are hopefully going to reduce
the number of groups and events. I'm somewhat agnostic as to what the
flag functionality should be as what I'm working with needs either the
default or --metric-no-group, I can use whatever flag is agreed upon.

Thanks,
Ian

> thanks,
> jirka
>
>
> >
> > > I was wondering if we could merge all the hasmaps into single
> > > one before the parse the evlist.. this way we won't need removing
> > > later.. but I did not thought this through completely, so it
> > > might not work at some point
> >
> > This could be done in the --metric-no-group case reasonably easily
> > like the current hashmap. For groups you'd want something like a set
> > of sets of events, but then you'd only be able to share events if the
> > sets were the same. A directed acyclic graph could capture the events
> > and the sharing relationships, it may be possible to optimize cases
> > like {A,B,C}, {A,B,D}, {A,B} so that the small group on the end shares
> > events with both the {A,B,C} and {A,B,D} group. This may be good
> > follow up work. We could also solve this in the json, for example
> > create a "phony" group of {A,B,C,D} that all three metrics share from.
> > You could also use --metric-no-group to achieve that sharing now.
> >
> > Thanks,
> > Ian
> >
> > > jirka
> > >
> >
>

  reply index

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-20  7:28 [PATCH 0/7] Share events between metrics Ian Rogers
2020-05-20  7:28 ` [PATCH 1/7] perf metricgroup: Change evlist_used to a bitmap Ian Rogers
2020-05-20 13:14   ` Jiri Olsa
2020-05-20 13:35     ` Arnaldo Carvalho de Melo
2020-05-20  7:28 ` [PATCH 2/7] perf metricgroup: Always place duration_time last Ian Rogers
2020-05-20  7:28 ` [PATCH 3/7] perf metricgroup: Delay events string creation Ian Rogers
2020-05-20 13:14   ` Jiri Olsa
2020-05-20 18:22     ` Ian Rogers
2020-05-20 20:34       ` Arnaldo Carvalho de Melo
2020-05-20 22:10         ` Jiri Olsa
2020-05-20  7:28 ` [PATCH 4/7] perf metricgroup: Order event groups by size Ian Rogers
2020-05-20  7:28 ` [PATCH 5/7] perf metricgroup: Remove duped metric group events Ian Rogers
2020-05-20 13:48   ` Jiri Olsa
2020-05-20 16:50     ` Ian Rogers
2020-05-20 22:09       ` Jiri Olsa
2020-05-20 22:42         ` Ian Rogers [this message]
2020-05-21 10:54           ` Jiri Olsa
2020-05-21 17:26             ` Ian Rogers
2020-05-21 17:28               ` Arnaldo Carvalho de Melo
2020-05-20  7:28 ` [PATCH 6/7] perf metricgroup: Add options to not group or merge Ian Rogers
2020-05-20  7:28 ` [PATCH 7/7] perf metricgroup: Remove unnecessary ',' from events Ian Rogers
2020-05-20 13:13 ` [PATCH 0/7] Share events between metrics Jiri Olsa
2020-05-20 14:50   ` Ian Rogers

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=fU12vP45Sg3uRSuz-xoceTPTKw9-XZieKv1PaTnREMdrw@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=bpf@vger.kernel.org \
    --cc=eranian@google.com \
    --cc=john.garry@huawei.com \
    --cc=jolsa@redhat.com \
    --cc=kan.liang@linux.intel.com \
    --cc=kim.phillips@amd.com \
    --cc=kjain@linux.ibm.com \
    --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=pc@us.ibm.com \
    --cc=peterz@infradead.org \
    --cc=songliubraving@fb.com \
    --cc=srikar@linux.vnet.ibm.com \
    --cc=vincent.weaver@maine.edu \
    --cc=xiyou.wangcong@gmail.com \
    --cc=yao.jin@linux.intel.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

BPF Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/bpf/0 bpf/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 bpf bpf/ https://lore.kernel.org/bpf \
		bpf@vger.kernel.org
	public-inbox-index bpf

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.bpf


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git