From: Ben Gainey <Ben.Gainey@arm.com>
To: "ak@linux.intel.com" <ak@linux.intel.com>
Cc: "irogers@google.com" <irogers@google.com>,
"alexander.shishkin@linux.intel.com"
<alexander.shishkin@linux.intel.com>,
James Clark <James.Clark@arm.com>,
"peterz@infradead.org" <peterz@infradead.org>,
Mark Rutland <Mark.Rutland@arm.com>,
"linux-perf-users@vger.kernel.org"
<linux-perf-users@vger.kernel.org>,
"mingo@redhat.com" <mingo@redhat.com>,
"acme@kernel.org" <acme@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"jolsa@kernel.org" <jolsa@kernel.org>,
"namhyung@kernel.org" <namhyung@kernel.org>,
"adrian.hunter@intel.com" <adrian.hunter@intel.com>
Subject: Re: [PATCH 0/1] Support PERF_SAMPLE_READ with inherit_stat
Date: Fri, 19 Jan 2024 18:08:52 +0000 [thread overview]
Message-ID: <e69ffb457b761763c30e2d63ffd8a38606dbadd3.camel@arm.com> (raw)
In-Reply-To: <87a5p1kyif.fsf@linux.intel.com>
On Fri, 2024-01-19 at 09:45 -0800, Andi Kleen wrote:
> Ben Gainey <ben.gainey@arm.com> writes:
>
> > In this configuration stream ids (such as may appear in the
> > read_format
> > field of a PERF_RECORD_SAMPLE) are no longer globally unique,
> > rather
> > the pair of (stream id, tid) uniquely identify each event. Tools
> > that
> > rely on this, for example to calculate a delta between samples,
> > would
> > need updating to take this into account. Previously valid event
> > configurations (system-wide, no-inherit and so on) where each
> > stream id
> > is the identifier are unaffected.
>
> So is this an ABI break? It might need an optin, if it breaks
> anything,
> which wouldn't surprise me. We do have a lot of different perf stream
> parsers around these days and we cannot break them.
>
> -Andi
I had considered that, but given currently this perf_event_attr
configuration is not allowed, I assumed that it would require existing
tools to add support which would in effect be an opt-in. Of course,
adding a new flag to be explicit would be trivial enough if required.
That said, the binary format for the mmap records / read() etc does not
change so using an unmodified tool to parse the data file will give bad
results. Therefore any workflow where "modified recording tool" can be
combined with "older / unmodified parsing tool" will break. Not sure of
the best way to handle this... presumably whenever a change is made to
the perf record format, any workflow that allows old parsers to read
new format data without version checks could fail? Admittedly this is a
"looks the same but isn't" change so harder for tools devs to spot. Any
suggestions?
For the perf tools, is there a means to record in perf.data a minimum
supported tool version / feature incompatibility flags?
Regards
Ben
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
next prev parent reply other threads:[~2024-01-19 18:09 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-19 16:39 [PATCH 0/1] Support PERF_SAMPLE_READ with inherit_stat Ben Gainey
2024-01-19 16:39 ` [PATCH 1/1] perf: " Ben Gainey
2024-01-19 17:45 ` [PATCH 0/1] " Andi Kleen
2024-01-19 18:08 ` Ben Gainey [this message]
2024-01-19 22:55 ` Andi Kleen
2024-01-20 0:49 ` Namhyung Kim
2024-01-20 16:14 ` Ben Gainey
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=e69ffb457b761763c30e2d63ffd8a38606dbadd3.camel@arm.com \
--to=ben.gainey@arm.com \
--cc=James.Clark@arm.com \
--cc=Mark.Rutland@arm.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).